From owner-freebsd-current@freebsd.org Sun Oct 18 13:22:26 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 927D4431C0A for ; Sun, 18 Oct 2020 13:22:26 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from smtp.vangyzen.net (hotblack.vangyzen.net [199.48.133.146]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4CDgXw6lp8z4TBs for ; Sun, 18 Oct 2020 13:22:24 +0000 (UTC) (envelope-from eric@vangyzen.net) Received: from disco.vangyzen.net (unknown [70.97.188.230]) by smtp.vangyzen.net (Postfix) with ESMTPSA id 5D4FF5646C for ; Sun, 18 Oct 2020 08:22:18 -0500 (CDT) To: freebsd-current From: Eric van Gyzen Subject: top ARC stats are wrong Message-ID: Date: Sun, 18 Oct 2020 08:22:12 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4CDgXw6lp8z4TBs X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.45 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(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]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.98)[-0.979]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[vangyzen.net:+]; DMARC_POLICY_ALLOW(-0.50)[vangyzen.net,none]; NEURAL_HAM_SHORT(-0.48)[-0.475]; R_SPF_ALLOW(-0.20)[+a]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:36236, ipnet:199.48.132.0/22, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Oct 2020 13:22:26 -0000 I would love to have 2 TB of RAM, but alas, I have a paltry 32 GB, and only 200 GB of disk used by ZFS: ARC: 1860M Total, 612G MFU, K MRU, 1921G Anon, 12M Header, 157M Other NAME SIZE ALLOC FREE .......... 230G 178G 51.7G .......... 298G 12.6G 285G This is on r366500+84ccaf49083c-c272054. I'll look into it when I have time, but that won't be soon. Eric From owner-freebsd-current@freebsd.org Sun Oct 18 15:52:19 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3E53A435C95 for ; Sun, 18 Oct 2020 15:52:19 +0000 (UTC) (envelope-from wlosh@bsdimp.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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CDkst446Rz4fDW for ; Sun, 18 Oct 2020 15:52:18 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qv1-xf30.google.com with SMTP id de3so3302769qvb.5 for ; Sun, 18 Oct 2020 08:52:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CaERgYKw81i2o+j6PVBzZkhYlUsdg7MJTjF7jIHJB/Y=; b=q78bbHPx5XBzJorYVviwL6eNNIAQJEcMe7swRs2tJiBvy5H6q/RQsere+ncSxt9CZS yS7vS21vGpebIo3EDHsHkr4BN66d/8jjI9p6ARtjp6+8uVH+/P98GhuePv6xWPcvQd+5 nh7WoXIbb11JAFXX7WdhNmOMQyCvwnGWdUWGn3ScHcEEUYbBGYkcssG0kpWulvLzdk3l wqs+gtss+7BPI0DNLofmv0gj+SNSz1EXnoWDHvxtjge6KFR/3K9fAW2ib7vLBOEsUOaj sbUBD3MaAmFug2juGuV2ptLHL48TPf88/2dkEF4Ln69JMS5AlEMRl+Kelbb2XNseQPrP LbeA== X-Gm-Message-State: AOAM530tlJEafMCnGclRE9YVnTP8MXHeo8c4YGSBgX+0co94A5CyRAp9 uNrVNd7hBagxiDZAR1WP44UxONDGUampPpYzp0zWr73lmT/gMA== X-Google-Smtp-Source: ABdhPJzJt3m1ojf4RGk6bXlqrRzpdI/pWKWBlZXTCvioqvzBjK0BEYW9XrALbmZ5Wd9zPIlyv+N1AToG3tuvJApV+bo= X-Received: by 2002:a0c:e40c:: with SMTP id o12mr13377598qvl.29.1603036337354; Sun, 18 Oct 2020 08:52:17 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Sun, 18 Oct 2020 09:52:06 -0600 Message-ID: Subject: Re: bug in motd service / documentation To: Dan Mack Cc: FreeBSD Current X-Rspamd-Queue-Id: 4CDkst446Rz4fDW X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.22 / 15.00]; ARC_NA(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-0.94)[-0.942]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.96)[-0.962]; 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.20150623.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f30:from]; NEURAL_HAM_SHORT(-0.32)[-0.318]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Oct 2020 15:52:19 -0000 On Sat, Oct 17, 2020 at 2:46 PM Dan Mack wrote: > On Sat, 17 Oct 2020, Dan Mack wrote: > > > I've been away for a while and missed the change and complexity added to > > /etc/motd. I figured it out but I was led astray by not knowing that > it was > > converted into a service that only runs at boot time. If you just > follow the > > instructions in the template file, you will nothing changes. > > > > As a suggestion, maybe change this line in the /etc/motd.template file: > > > > Edit /etc/motd.template to change this login announcement. > > > > to: > > > > Edit /etc/motd.template to change this login announcement and > > reboot or manually restart the motd service in /etc/rc.d/motd as in: > > > > /etc/rc.d/motd restart > > > > and also add an entry to the man page for motd. > > > > This was on: FreeBSD boxolox 13.0-CURRENT FreeBSD 13.0-CURRENT #1 > > r366790: Sat Oct 17 08:57:56 CDT 2020 > > Instead of just complaining, I've attached a diff of a proposed > fix. Diff against base/head is here fwiw: > https://github.com/danmack/freebsd/tree/motd-doc-fix Thanks Dan. I'll commit this if someone doesn't beat me to it. Warner From owner-freebsd-current@freebsd.org Mon Oct 19 15:07:19 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 410B942AD2D for ; Mon, 19 Oct 2020 15:07:19 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from tor1-11.mx.scaleengine.net (tor1-11.mx.scaleengine.net [IPv6:2001:470:1:474::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 4CFKqV2wkMz3TVZ for ; Mon, 19 Oct 2020 15:07:17 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [10.1.1.2] (Seawolf.HML3.ScaleEngine.net [209.51.186.28]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by tor1-11.mx.scaleengine.net (Postfix) with ESMTPSA id 393BD24378 for ; Mon, 19 Oct 2020 15:07:08 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.10.3 tor1-11.mx.scaleengine.net 393BD24378 To: freebsd-current@freebsd.org References: From: Allan Jude Autocrypt: addr=allanjude@freebsd.org; prefer-encrypt=mutual; keydata= xsFNBFVwZcYBEADwrZDH0xe0ZVjc9ORCc6PcBLwS/RTXA6NkvpD6ea02pZ8lPOVgteuuugFc D34LdDbiWr+479vfrKBh+Y38GL0oZ0/13j10tIlDMHSa5BU0y6ACtnhupFvVlQ57+XaJAb/q 7qkfSiuxVwQ3FY3PL3cl1RrIP5eGHLA9hu4eVbu+FOX/q/XVKz49HaeIaxzo2Q54572VzIo6 C28McX9m65UL5fXMUGJDDLCItLmehZlHsQQ+uBxvODLFpVV2lUgDR/0rDa0B9zHZX8jY8qQ7 ZdCSy7CwClXI054CkXZCaBzgxYh/CotdI8ezmaw7NLs5vWNTxaDEFXaFMQtMVhvqQBpHkfOD 7rjjOmFw00nJL4FuPE5Yut0CPyx8vLjVmNJSt/Y8WxxmhutsqJYFgYfWl/vaWkrFLur/Zcmz IklwLw35HLsCZytCN5A3rGKdRbQjD6QPXOTJu0JPrJF6t2xFkWAT7oxnSV0ELhl2g+JfMMz2 Z1PDmS3NRnyEdqEm7NoRGXJJ7bgxDbN+9SXTyOletqGNXj/bSrBvhvZ0RQrzdHAPwQUfVSU2 qBhQEi2apSZstgVNMan0GUPqCdbE2zpysg+zT7Yhvf9EUQbzPL4LpdK1llT9fZbrdMzEXvEF oSvwJFdV3sqKmZc7b+E3PuxK6GTsKqaukd/3Cj8aLHG1T1im1QARAQABzSJBbGxhbiBKdWRl IDxhbGxhbmp1ZGVAZnJlZWJzZC5vcmc+wsF/BBMBAgApBQJVcGXGAhsjBQkSzAMABwsJCAcD AgEGFQgCCQoLBBYCAwECHgECF4AACgkQGZU1PhKYC34Muw/+JOKpSfhhysWFYiRXynGRDe07 Z6pVsn7DzrPUMRNZfHu8Uujmmy3p2nx9FelIY9yjd2UKHhug+whM54MiIFs90eCRVa4XEsPR 4FFAm0DAWrrb7qhZFcE/GhHdRWpZ341WAElWf6Puj2devtRjfYbikvj5+1V1QmDbju7cEw5D mEET44pTuD2VMRJpu2yZZzkM0i+wKFuPxlhqreufA1VNkZXI/rIfkYWK+nkXd9Efw3YdCyCQ zUgTUCb88ttSqcyhik/li1CDbXBpkzDCKI6I/8fAb7jjOC9LAtrZJrdgONywcVFoyK9ZN7EN AVA+xvYCmuYhR/3zHWH1g4hAm1v1+gIsufhajhfo8/wY1SetlzPaYkSkVQLqD8T6zZyhf+AN bC7ci44UsiKGAplB3phAXrtSPUEqM86kbnHg3fSx37kWKUiYNOnx4AC2VXvEiKsOBlpyt3dw WQbOtOYM+vkfbBwDtoGOOPYAKxc4LOIt9r+J8aD+gTooi9Eo5tvphATf9WkCpl9+aaGbSixB tUpvQMRnSMqTqq4Z7DeiG6VMRQIjsXDSLJEUqcfhnLFo0Ko/RiaHd5xyAQ4DhQ9QpkyQjjNf /3f/dYG7JAtoD30txaQ5V8uHrz210/77DRRX+HJjEj6xCxWUGvQgvEZf5XXyxeePvqZ+zQyT DX61bYw6w6bOwU0EVXBlxgEQAMy7YVnCCLN4oAOBVLZ5nUbVPvpUhsdA94/0/P+uqCIh28Cz ar56OCX0X19N/nAWecxL4H32zFbIRyDB2V/MEh4p9Qvyu/j4i1r3Ex5GhOT2hnit43Ng46z5 29Es4TijrHJP4/l/rB2VOqMKBS7Cq8zk1cWqaI9XZ59imxDNjtLLPPM+zQ1yE3OAMb475QwN UgWxTMw8rkA7CEaqeIn4sqpTSD5C7kT1Bh26+rbgJDZ77D6Uv1LaCZZOaW52okW3bFbdozV8 yM2u+xz2Qs8bHz67p+s+BlygryiOyYytpkiK6Iy4N7FTolyj5EIwCuqzfk0SaRHeOKX2ZRjC qatkgoD/t13PNT38V9tw3qZVOJDS0W6WM8VSg+F+bkM9LgJ8CmKV+Hj0k3pfGfYPOZJ/v18i +SmZmL/Uw2RghnwDWGAsPCKu4uZR777iw7n9Io6Vfxndw2dcS0e9klvFYoaGS6H2F13Asygr WBzFNGFQscN4mUW+ZYBzpTOcHkdT7w8WS55BmXYLna+dYer9/HaAuUrONjujukN4SPS1fMJ2 /CS/idAUKyyVVX5vozoNK2JVC1h1zUAVsdnmhEzNPsvBoqcVNfyqBFROEVLIPwq+lQMGNVjH ekLTKRWf59MEhUC2ztjSKkGmwdg73d6xSXMuq45EgIJV2wPvOgWQonoHH/kxABEBAAHCwWUE GAECAA8FAlVwZcYCGwwFCRLMAwAACgkQGZU1PhKYC34w5A//YViBtZyDV5O+SJT9FFO3lb9x Zdxf0trA3ooCt7gdBkdnBM6T5EmjgVZ3KYYyFfwXZVkteuCCycMF/zVw5eE9FL1+zz9gg663 nY9q2F77TZTKXVWOLlOV2bY+xaK94U4ytogOGhh9b4UnQ/Ct3+6aviCF78Go608BXbmF/GVT 7uhddemk7ItxM1gE5Hscx3saxGKlayaOsdPKeGTVJCDEtHDuOc7/+jGh5Zxpk/Hpi+DUt1ot 8e6hPYLIQa4uVx4f1xxxV858PQ7QysSLr9pTV7FAQ18JclCaMc7JWIa3homZQL/MNKOfST0S 2e+msuRwQo7AnnfFKBUtb02KwpA4GhWryhkjUh/kbVc1wmGxaU3DgXYQ5GV5+Zf4kk/wqr/7 KG0dkTz6NLCVLyDlmAzuFhf66DJ3zzz4yIo3pbDYi3HB/BwJXVSKB3Ko0oUo+6/qMrOIS02L s++QE/z7K12CCcs7WwOjfCYHK7VtE0Sr/PfybBdTbuDncOuAyAIeIKxdI2nmQHzl035hhvQX s4CSghsP319jAOQiIolCeSbTMD4QWMK8RL/Pe1FI1jC3Nw9s+jq8Dudtbcj2UwAP/STUEbJ9 5rznzuuhPjE0e++EU/RpWmcaIMK/z1zZDMN+ce2v1qzgV936ZhJ3iaVzyqbEE81gDxg3P+IM kiYh4ZtPB4Q= Subject: Re: top ARC stats are wrong Message-ID: Date: Mon, 19 Oct 2020 11:07:03 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GQV4yU3YNKO0G9uF1iOiWHBMU2VdoSmGB" X-Rspamd-Queue-Id: 4CFKqV2wkMz3TVZ X-Spamd-Bar: / X-Spamd-Result: default: False [0.00 / 15.00]; local_wl_from(0.00)[freebsd.org]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 15:07:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --GQV4yU3YNKO0G9uF1iOiWHBMU2VdoSmGB Content-Type: multipart/mixed; boundary="4fZLSbJfPDKA3BCMJOlrk2ApshwNliXSz"; protected-headers="v1" From: Allan Jude To: freebsd-current@freebsd.org Message-ID: Subject: Re: top ARC stats are wrong References: In-Reply-To: --4fZLSbJfPDKA3BCMJOlrk2ApshwNliXSz Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 2020-10-18 09:22, Eric van Gyzen wrote: > I would love to have 2 TB of RAM, but alas, I have a paltry 32 GB, and > only 200 GB of disk used by ZFS: >=20 > ARC: 1860M Total, 612G MFU, K MRU, 1921G Anon, 12M Header, 157M Other >=20 > NAME=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 SIZE=C2=A0 ALLOC=C2= =A0=C2=A0 FREE > ..........=C2=A0=C2=A0 230G=C2=A0=C2=A0 178G=C2=A0 51.7G > ..........=C2=A0=C2=A0 298G=C2=A0 12.6G=C2=A0=C2=A0 285G >=20 > This is on r366500+84ccaf49083c-c272054. >=20 > I'll look into it when I have time, but that won't be soon. >=20 > Eric > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" I had seen this as well, I noticed the kstat sysctls seemed to be correct, so I am wondering if the size changes or something, and so top is misreading it. I also have not had a chance to dig into it. --=20 Allan Jude --4fZLSbJfPDKA3BCMJOlrk2ApshwNliXSz-- --GQV4yU3YNKO0G9uF1iOiWHBMU2VdoSmGB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJfjauaAAoJEBmVNT4SmAt+JBsP/iROyIdUwQiwHltnmXQtgw64 Vquu4tYAvN2dIlmbHrvlDxyixgJUtOpPf4EEGMFgrfCTMUxzV04Gxp0W07fqtW3q AUWaO+HW5sjvryvzvg6crW9tBH8LDBVNzkgyM0ueDFENA+JIZdRuRI2umDewiOQy sQ7VaAUJ09yUzDJfEs4bgcDjYHq10TW26HJXHJqwu/zF47HgZukhcKDlB4gKbxen YGZ9l4Ki4fNn1iPv9Au858idNvxc90ApI8a+oPd36vMudA0dGzrqCmg4JBO+qAKM 1//UYdLfe/8hu0rMHy78CZWiVBY3DwJ2onnNiZqifMUKONYHXuqs6INIQLyD1xdr Glw8w+mdG3DDlsWs5zZlBSUZJdQhegIshnxrV5F/S7UAaGolSMwWYgGUM83hvRia ucJFk48LBLLCGVSrKH4rCFfxHJUKZPOAWVi9wybW8aNtydHzp4M48gdYv/bJl2eg mEQK4BbmkFopEZYzcOYFfLp0iVkEGXUfVdhhQNELX2TnXJfXM3cFIbuTWcdbSxEh Mhs4hxXBQcdqIt0/C0DFcwbuVQB4fvKd5+b5LBitSpMp2yVRM6QptAMb3+qbBpui 7pt2kcvZA1KpNYQpYg05wkBTj5F9vC3sn+BzHB1/pfuP36otlkemEJL5A8r5osWg xm1bD0/pOpNp8YhoMp7t =11Ep -----END PGP SIGNATURE----- --GQV4yU3YNKO0G9uF1iOiWHBMU2VdoSmGB-- From owner-freebsd-current@freebsd.org Mon Oct 19 20:39:59 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id DC499434481; Mon, 19 Oct 2020 20:39:59 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-io1-xd41.google.com (mail-io1-xd41.google.com [IPv6:2607:f8b0:4864:20::d41]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CFTCL3Ff9z48j6; Mon, 19 Oct 2020 20:39:58 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-io1-xd41.google.com with SMTP id q25so1457485ioh.4; Mon, 19 Oct 2020 13:39:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=CmoJc3Se4kYJ4D0w5hM+bPiL1uZ+22dXmJZbpjxT7vQ=; b=OXs8+RCGtOxL6n/WkVwq+3dFEm11mniP+nIDtdarmI0oKMzgxvw27ijbhfwG0J84tS sGfy9D6f0P+pBdHct5OKsfyOAMzifNGFrP2iE6n2GY1H+kBRLcf8hPyJnIBYeNAdkiwJ ce/1G18kNjvDTtyrSQ/hJOw7E1v75W+WUK1ej60FmPHuVYsJgtn/p8c8jcA1OE/9AQ2L nTR+FlqNtdKzi2ng+LqUm5A7n0xtAdE8vCny46vQdsv3+JiaHabZJnA+/GoPnePXt8SZ 9p6UdZRDTRaqBnBqIZCyGcqjw3DSVVZI6N2LcmDQyMqbQHPGPrpI0K5vc/QDCz8V1i85 b87Q== X-Gm-Message-State: AOAM530cDf5fdgyUJFzgG9YUP5/CFJgF1kakrEwcxEogHdHRbm4nfMwc CqZqo/LRjNtslPEerPcyWmQHrold4PM= X-Google-Smtp-Source: ABdhPJxj18hsbo193UotBMD0F8QtF4mwEBjjIO6XZobfvfqfP17Z8P67HgDEGKXfs5BEYZpZrzGbcQ== X-Received: by 2002:a02:a798:: with SMTP id e24mr1531280jaj.105.1603139997051; Mon, 19 Oct 2020 13:39:57 -0700 (PDT) Received: from raichu (toroon0560w-lp130-01-174-88-77-103.dsl.bell.ca. [174.88.77.103]) by smtp.gmail.com with ESMTPSA id h14sm766399ilc.38.2020.10.19.13.39.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 19 Oct 2020 13:39:56 -0700 (PDT) Sender: Mark Johnston Date: Mon, 19 Oct 2020 16:39:54 -0400 From: Mark Johnston To: mmel@freebsd.org Cc: bob prohaska , freebsd-current@freebsd.org, freebsd-arm@freebsd.org Subject: Re: panic: non-current pmap 0xffffa00020eab8f0 on Rpi3 Message-ID: <20201019203954.GC46122@raichu> References: <20201006021029.GA13260@www.zefox.net> <20201006133743.GA96285@raichu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4CFTCL3Ff9z48j6 X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.62 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; NEURAL_HAM_LONG(-1.02)[-1.020]; MIME_GOOD(-0.10)[text/plain]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_NA(0.00)[freebsd.org]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; NEURAL_HAM_SHORT(-0.89)[-0.893]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::d41:from]; NEURAL_HAM_MEDIUM(-1.01)[-1.009]; 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]; MAILMAN_DEST(0.00)[freebsd-current,freebsd-arm] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 20:39:59 -0000 On Fri, Oct 16, 2020 at 11:53:56AM +0200, Michal Meloun wrote: > > > On 06.10.2020 15:37, Mark Johnston wrote: > > On Mon, Oct 05, 2020 at 07:10:29PM -0700, bob prohaska wrote: > >> Still seeing non-current pmap panics on the Pi3, this time a B+ running > >> 13.0-CURRENT (GENERIC-MMCCAM) #0 71e02448ffb-c271826(master) > >> during a -j4 buildworld. The backtrace reports > >> > >> panic: non-current pmap 0xffffa00020eab8f0 > > > > Could you show the output of "show procvm" from the debugger? > > I see same panic too, in my case its very rare - typical scenario is > rebuild of kf5 ports (~250, 2 days of full load). Any idea how to debug > this? > Michal I suspect that there is some race involving the pmap switching in vmspace_exit(), but I can't see it. In the example below, presumably process 22604 on CPU 0 is also exiting? Could you show the backtrace? It would also be useful to see the value of PCPU_GET(curpmap) at the time of the panic. I'm not sure if there's a way to get that from DDB, but I suspect it should be equal to &vmspace0->vm_pmap. I think vmspace_exit() should issue a release fence with the cmpset and an acquire fence when handling the refcnt == 1 case, but I don't see why that would make a difference here. So, if you can test a debug patch, this one will yield a bit more debug info. If you can provide access to a vmcore and kernel debug symbols, that'd be even better. diff --git a/sys/arm64/arm64/pmap.c b/sys/arm64/arm64/pmap.c index 284f00b3cc0d..3c53ae3b4c1e 100644 --- a/sys/arm64/arm64/pmap.c +++ b/sys/arm64/arm64/pmap.c @@ -4838,7 +4838,8 @@ pmap_remove_pages(pmap_t pmap) int allfree, field, freed, idx, lvl; vm_paddr_t pa; - KASSERT(pmap == PCPU_GET(curpmap), ("non-current pmap %p", pmap)); + KASSERT(pmap == PCPU_GET(curpmap), + ("non-current pmap %p %p", pmap, PCPU_GET(curpmap))); lock = NULL; diff --git a/sys/vm/vm_map.c b/sys/vm/vm_map.c index c20005ae64cf..0ad415e3b88c 100644 --- a/sys/vm/vm_map.c +++ b/sys/vm/vm_map.c @@ -358,7 +358,10 @@ vmspace_exit(struct thread *td) p = td->td_proc; vm = p->p_vmspace; atomic_add_int(&vmspace0.vm_refcnt, 1); - refcnt = vm->vm_refcnt; + refcnt = atomic_load_int(&vm->vm_refcnt); + + KASSERT(vmspace_pmap(vm) == PCPU_GET(curpmap), + ("non-current pmap %p %p", pmap, PCPU_GET(curpmap))); do { if (refcnt > 1 && p->p_vmspace != &vmspace0) { /* Switch now since other proc might free vmspace */ From owner-freebsd-current@freebsd.org Mon Oct 19 23:09:06 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 15B53437741; Mon, 19 Oct 2020 23:09:06 +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 4CFXWP4GYCz4KRW; Mon, 19 Oct 2020 23:09:03 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id 09JN9AtF066727 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Mon, 19 Oct 2020 16:09:10 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id 09JN9AMo066726; Mon, 19 Oct 2020 16:09:10 -0700 (PDT) (envelope-from fbsd) Date: Mon, 19 Oct 2020 16:09:09 -0700 From: bob prohaska To: Mark Johnston Cc: mmel@freebsd.org, freebsd-current@freebsd.org, freebsd-arm@freebsd.org, bob prohaska Subject: Re: panic: non-current pmap 0xffffa00020eab8f0 on Rpi3 Message-ID: <20201019230909.GA66675@www.zefox.net> References: <20201006021029.GA13260@www.zefox.net> <20201006133743.GA96285@raichu> <20201019203954.GC46122@raichu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201019203954.GC46122@raichu> X-Rspamd-Queue-Id: 4CFXWP4GYCz4KRW X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; REPLY(-4.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Oct 2020 23:09:06 -0000 On Mon, Oct 19, 2020 at 04:39:54PM -0400, Mark Johnston wrote: > > I think vmspace_exit() should issue a release fence with the cmpset and > an acquire fence when handling the refcnt == 1 case, but I don't see why > that would make a difference here. So, if you can test a debug patch, > this one will yield a bit more debug info. If you can provide access to > a vmcore and kernel debug symbols, that'd be even better. > I haven't seen an invalid pmap panic since the report of October 5th. Your patch applied cleanly on the Pi3 running HEAD at r366780M, the M being due to patches supplied by Kyle Evans applied to M sys/arm/broadcom/bcm2835/bcm2835_mbox.c M sys/arm/broadcom/bcm2835/bcm2835_sdhci.c M sys/arm/broadcom/bcm2835/bcm2835_vcbus.c M sys/arm/broadcom/bcm2835/bcm2835_vcbus.h AIUI, they're something to do with DMA for peripherals. They've caused no obvious trouble, if you anticipate conflicts let me know and I'll remove them I've never seen either a vmcore file or debug symbols on this machine. A sequence of instructions to generate the data needed would be helpful. Thanks for reading! bob prohaska From owner-freebsd-current@freebsd.org Tue Oct 20 00:56:16 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4A7E043955F for ; Tue, 20 Oct 2020 00:56:16 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-to1can01on0614.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe5d::614]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CFZv25f9kz4QCm for ; Tue, 20 Oct 2020 00:56:11 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CnGf/qpsRj+ibtj4cnNgG5i2/2YVSzgGwNUTBIySPNmlpBzfoWLDhaB8t8hAv5e/vmK3O9pcfmMY3EjJPlFtyVDksqA+vwMjS+Met7l+GDzpy+u2OqU5KnpK1D8v9SJRucMfh7iyjq3LXM1iPzSbVmVlgdZdhmbdPbURWuKWCPtVffnc/MX2Kqlp9bH1NsBwFxX3xsEPex77Kl2tAPOU43T2wguxdTDo5qEMz1i+RMN/gVXVok3ouVT88k7LsEEhwY7IWCW68T/4FJgCYCKdhK352auTkf7AxY3XwFjtot8sLUR8m99Hqhvg9Xa/maJEPuo0jOL8UnN6/uRc0uTDvQ== 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-SenderADCheck; bh=anRt9PwklLxxHxsjSnXeLZ9v5fp4ANowKKgliJj7flE=; b=GX0q4fGPokpfRxzdM/EMe7hIEdgZqFaWZ10mmm3NM3RcHzpfaUQ7c0D4TkrzPS8rmeWNGO6Mmf7RqoK5/8KzhG68lscszCqvlBH95nbVRoLAn6Ap/0QA5tSEFSfsCRnaV7pDW6U/p5o9psiNTphcZR52AmnpOvEYnU9FavI1Bt3UzBYq+KkGQVKmnatMqBIlkTd9j3crJLo8P5KzhuVfP0fjgIXL6i87KbVDQUCUz2E3pcKBbMVo/F52OhYQCPJYxNpTaR4d9hXKh3cJr6r56I0x1QtrAlMOwhuRGSXkmj5mBqqfxOyeeyXgHQts/8l/HWyJ69Cqm6PthNwmnv7prw== 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 Received: from YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:24::27) by YTXPR0101MB2141.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b00:2::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.24; Tue, 20 Oct 2020 00:56:04 +0000 Received: from YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM ([fe80::687f:d85a:a0a3:bd20]) by YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM ([fe80::687f:d85a:a0a3:bd20%6]) with mapi id 15.20.3477.028; Tue, 20 Oct 2020 00:56:04 +0000 From: Rick Macklem To: "freebsd-current@FreeBSD.org" Subject: review of new mountd option disabling use of rpcbind Thread-Topic: review of new mountd option disabling use of rpcbind Thread-Index: AQHWpnttt8iTz/9j60mb0Wbz7GHaDg== Date: Tue, 20 Oct 2020 00:56:04 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9973b721-0d68-446c-b0ea-08d87492ebd5 x-ms-traffictypediagnostic: YTXPR0101MB2141: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 2Pj39+VsgASCYsMB7XHOmdkTRkDAE3sXiHl3oUbWQ7eEmosk3xfxzQppirLMPiFkQlOzH9YfGBzCiQvl8KcjgqRhN3lEgjMSDjENRch+HGV5HiyaiRUoHMk1zsdN2RKpaVvGVt+ZXLZt6xEZnASB+aw87pEVCuHv18DI2qZmWqlBqM2EtfQD+4PQ+i1/kvQT7zfTH1DD5v2DUiQ4nQn0UURTMALGq1+9CZUmCyI5yhJc+DlrUCHEJfFvaW9124Cuh+sQiYZdS0yTMNc2rXYYgzrt/8R3RXqzKLE2bmkzeRY9WR3+2H4IOOm2m2n9Y1JJiw8PnjlKDxl6uQcOIimIxA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(39860400002)(136003)(376002)(366004)(346002)(396003)(76116006)(52536014)(55016002)(786003)(316002)(8676002)(83380400001)(66556008)(64756008)(66476007)(6506007)(186003)(71200400001)(66446008)(66946007)(86362001)(8936002)(6916009)(33656002)(9686003)(478600001)(7696005)(4744005)(5660300002)(2906002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: hqMpWYknC3gI/Lf400XnsMEdeM9usg+/MVHw/hRzJziMQFiC8bC/0CBNAG8Yqm6sXu/LOpAdlQ3CIXNPOnmSqzuy4MoHjDVFhf4EBe8bKJw2koL1QHvifh2j+5HiHHbftJ6xTimIVPlogIpCY4pwYlM7DqaId8Ui0M2NOttljRxpjQ/UKeP+tfhb3CvjjxBSSIsjpaZfNGPrYYT7TxxHndnDJWB+hLDiCdUCl25tznFx+eM/Od//QgjKP63uJ70g0hEg7AW3xcvV/a/7hG+YR1AMAzei5LMYU2E0/KKlgcByHNkg8XzkCGuKZEUue5bxvYSWlSdVfDZxf8qPIEpdyzPfSlp2xwgx6vG/a7OxGbxnjp0lOyxBs9oFSK5AvRaQZxNyx0AOAEnxsSJ6TGDiHma0j3bLYWEgeQycLcJ4S92sSgoAL/e9PiWc6ZPyfJhc81HqKMxxHNrr5Mii5IpnPlyyyj3+GkjyA/YsM2+oewFFMDm9hFn3ZhbxQaoS6cD0GMKiyKrjTkTgJ1L2AgD5C8HxJkaKzXU0un/CxoAyICtYmWTWzFJIg9J13WXh6FadDQlG7Q11pF/mMBVlKOcdIXukp2WJEqnE2WFH6uGDI7zMvW3MDcumsr0w1Axs4l/C6KALQEm6J71FGYkI/3XQGXjkJbWL4clf4oPUkO7RPRWWgsf2WElU6P9oMJ3aWOX52CHZNqxbx2Fdu4c3ywD0eQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 9973b721-0d68-446c-b0ea-08d87492ebd5 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Oct 2020 00:56:04.2833 (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: rY05nKywH0kCia5bJcOLv2/onlhMpfFvxH+h4YFPWAG96lTsEqNXbIItigDaxh6lXd4SndC4KD+/AneawXWkrw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR0101MB2141 X-Rspamd-Queue-Id: 4CFZv25f9kz4QCm X-Spamd-Bar: ----- X-Spamd-Result: default: False [-5.47 / 15.00]; NEURAL_HAM_MEDIUM(-1.01)[-1.010]; R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector1]; FREEFALL_USER(0.00)[rmacklem]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a01:111:f400::/48]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.01)[-1.005]; RCPT_COUNT_ONE(0.00)[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]; NEURAL_HAM_SHORT(-0.46)[-0.455]; TO_DN_EQ_ADDR_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:8075, ipnet:2a01:111:f000::/36, country:US]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2020 00:56:16 -0000 Hi,=0A= =0A= I've put a patch up on phabricator that adds a new option to mountd=0A= which disables use of rpcbind. This can be done for NFSv4 only servers.=0A= It appears that rpcbind is now considered a security risk by some.=0A= =0A= I listed freqlabs@ as a reviewer, but if anyone else would like to review= =0A= it, please do so. (Someone has reviewed the man page update already.=0A= Thanks bcr@.)=0A= =0A= It's D26746.=0A= =0A= rick=0A= From owner-freebsd-current@freebsd.org Tue Oct 20 01:24:57 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id EF81443B874 for ; Tue, 20 Oct 2020 01:24:57 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-qb1can01on0615.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe5c::615]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CFbX835z2z4SST for ; Tue, 20 Oct 2020 01:24:55 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=R7j+x1H3K9KqeliPlpvz1RhznEvzxzF0Xwtq5XPuGaWhAV6NW4egpYL5rsVbdDBZJd4FkcAQr2xT9fX8SnQqqHwy21lKKaqO8rppLM0aGJLJum/sp9rODISSh6q+Mn1kTJukHSGaLIxASEWKQAkI/MBB7UT8mAfCilJ/1TYN0jKoehqFgXp+LQGsX9v4w7QwCqdY5tMSgICg9bKk/EJnh2YX64uYhX/4BLN+YJpN3qYyHX/EUcKIMAMLKa/GVh9fHt3UuFumidanFQIGMZ7lKlBIIsqIngfWBRK36wv5u7PW3K0q6O5zMa5J8LdcpMBt5Ah3m5MSSbQKK7UoIBJiMg== 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-SenderADCheck; bh=OOjbunAO/gqFDscx+rBqO/KMzcE2j/8k1b2ypJt8QQQ=; b=nHq3sy7Escy8tYApfhoo8kONZTdp4Nn7wCY5EgahRvss2xv3qisvLyUZwzDyidlFKOmP3PJllYHKdU3gZOjzBZjcIwCjbvUC677wBQJA9HfNCVdKCyu7q7qw02AcJv9f1FDHbus6cvB23SHbwqLuHIbg5NlVoKTLwlRSa7WzNw8DHqZs3JUhDG46z3TnzDheLPpGA4+yYczo1UKwkMUiGgVg3NaylFHH98ULCUIPdmQRpsSc3+MZDFcHoFCqXnBTU+VCCZ0A5zLCpr74fIswfEumuLHqTrRb9WwEjcb+O3jjxTEmTHep3h6cAieb46zXktebmHmcgtxYt0KklhDN/Q== 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 Received: from YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:24::27) by YTBPR01MB3437.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:1c::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.21; Tue, 20 Oct 2020 01:24:52 +0000 Received: from YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM ([fe80::687f:d85a:a0a3:bd20]) by YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM ([fe80::687f:d85a:a0a3:bd20%6]) with mapi id 15.20.3477.028; Tue, 20 Oct 2020 01:24:52 +0000 From: Rick Macklem To: "freebsd-current@FreeBSD.org" Subject: copyright notice question Thread-Topic: copyright notice question Thread-Index: AQHWpn7fxoWEd2ZfUkuqrM0B3buK/A== Date: Tue, 20 Oct 2020 01:24:52 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 85ec7807-c137-4a38-e424-08d87496f1cd x-ms-traffictypediagnostic: YTBPR01MB3437: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 4lEqWjrgCF7apuZv2/omNrpKY6HCbId5aEuo7aGH4Di4PQ5jzN7nTbfZ04++WWa0Z7ydXn044RncyaExUjMz1W5gOD4phHEbUYWgYTgvDoIkzKO2BdF+jffIiA5lL+g8/LHpKCM5iBbBvZlslsBEny0r1m5fkKxQ9RSZudsXUpIqYhP/m2r9ZCh9JCzcxJrDJk8MGVm38c2D/GkHnoYl9w7o4JcscKErTDXwlGgKRReA74J0nRN3VDVMW6nPJqqrXuZfcSz1TqP9ktrvxmJlDIKzI7Jh60y2BsFlb5+mknKhlGbJV+k4Ffh+vIa0r9zykcP06Bg9c8GT+B77YGvNGaboEUCppUTAPg4F75uzNIjG2jwdMAwdRJz0KXWWrxyRVTIchpIeRsFKdUenrDlZHxeC0NdDlQ52456kUxgpG5hyvh5cO9tjdBISobVP83CyGkZBggkjH6hVq0v/+Ih0Qg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(346002)(396003)(366004)(39860400002)(376002)(136003)(86362001)(33656002)(8936002)(19627235002)(8676002)(186003)(83380400001)(66556008)(66446008)(66946007)(76116006)(7696005)(6506007)(66476007)(64756008)(71200400001)(15650500001)(966005)(6916009)(9686003)(52536014)(5660300002)(55016002)(786003)(316002)(478600001)(2906002)(3480700007)(7116003)(133083001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: f0+8h1gDbYqNGsKPnQfaUv1DogA+lI/xBRDOsJStFFnugqBfU0a+bjMZx2nQdWINtqh1fwA3AtERRQHof/QMZI0BCzkiZCEek+7D3xZIIJmoYToOspL0GDleU6cbZm6gy5bku5j4C1oZyyrbkr4N4EpMbSxTWDauBG82OT4oxqw6CgTl2PuOtm6HToMAcBf5JNeuDuXi4DAKX942qJ9l4NT/4QD0MYixFXWAPtkrdjYu23E57rC20/1R/TWMsctstkr9GeOjcrdx+nH7gGVJwAPjAPwD/hlZoUBhQm43e0/UhyZnZ9ghVwJQzchnyiKMbDgoXFVuijeOIgM9DaUatek2vYAK2oT8+QBpDZG4jGw8Lcic0wY36BHgs8UXXxPRNPCnsmgc2E9L4oGlh3OcxUXCisLh5apWfsHc22aksF0S4jrQx+r+44N4g29vJvpfTZSajenIXtWdvZu32U4k6cAwTzyxBU951thX2URurvm39MDs6mwXf/ttJo8/vrhPILWHeuJgzi0fl+6nmnSh7/jrATUlt0GQAUEGxVfrhVVtqMZdCI+nHtnd06Jdu0BE9CJ6xHnfaYHBYvlG4Xo+1XQ1l0teUOvTr3JaoUAYUIhj1loC2QQ3aM76p/eg+rJMLn5KtsBpKm/3LAYF2/4NLHJpife4asFgdH5wvksaBWUKSZGJUf9eb+ZTrtKAQbvzTxsN+smgIZ1rsayiOS4yXA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 85ec7807-c137-4a38-e424-08d87496f1cd X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Oct 2020 01:24:52.2704 (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: ryIpgvfUtKph+GPGTO6nGzfmot6LRyDYAffsF1xlLF/BhmgmYpMYqpFJZXqDkwCS7d0lodwftPMN2Zr1mEM5yg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTBPR01MB3437 X-Rspamd-Queue-Id: 4CFbX835z2z4SST X-Spamd-Bar: ----- X-Spamd-Result: default: False [-5.45 / 15.00]; NEURAL_HAM_MEDIUM(-1.01)[-1.008]; R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector1]; FREEFALL_USER(0.00)[rmacklem]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a01:111:f400::/48]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.01)[-1.006]; RCPT_COUNT_ONE(0.00)[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]; NEURAL_HAM_SHORT(-0.44)[-0.439]; TO_DN_EQ_ADDR_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:8075, ipnet:2a01:111:f000::/36, country:US]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2020 01:24:58 -0000 I'll admit I've hesitated to ask this for a long time, but I guess I have t= o;-)=0A= I've created two daemons for NFS-over-TLS, using the code in=0A= /usr/src/usr.sbin/gssd/gssd.c as a starting point.=0A= --> As such, I left the copyright notice from this file on the two files.= =0A= (As you can see, it is a 2 clause FreeBSD one, so the terms aren't=0A= an issue.)=0A= =0A= What I am wondering is if I should be adding my name to it as an=0A= additional author or something like that?=0A= (I don't care, but it does seem a little weird that the copyright is held= =0A= by Isilon Inc, since I have no connection to them.)=0A= =0A= Here's what it currently says:=0A= /*-=0A= * SPDX-License-Identifier: BSD-2-Clause-FreeBSD=0A= *=0A= * Copyright (c) 2008 Isilon Inc http://www.isilon.com/=0A= * Authors: Doug Rabson =0A= * Developed with Red Inc: Alfred Perlstein =0A= *=0A= * Redistribution and use in source and binary forms, with or without=0A= * modification, are permitted provided that the following conditions=0A= * are met:=0A= * 1. Redistributions of source code must retain the above copyright=0A= * notice, this list of conditions and the following disclaimer.=0A= * 2. Redistributions in binary form must reproduce the above copyright=0A= * notice, this list of conditions and the following disclaimer in the= =0A= * documentation and/or other materials provided with the distribution.= =0A= *=0A= * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND= =0A= * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE=0A= * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPO= SE=0A= * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE= =0A= * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTI= AL=0A= * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS= =0A= * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)=0A= * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRI= CT=0A= * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WA= Y=0A= * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF= =0A= * SUCH DAMAGE.=0A= */=0A= =0A= Thanks for any comments, rick=0A= From owner-freebsd-current@freebsd.org Tue Oct 20 01:55:13 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9D73543D82C for ; Tue, 20 Oct 2020 01:55:13 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CFcC43vLqz4W0W for ; Tue, 20 Oct 2020 01:55:12 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x82a.google.com with SMTP id q26so81361qtb.5 for ; Mon, 19 Oct 2020 18:55:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7Bli16pbabdV2JrrHkOxU8PLoBTzOQCEX7F3/NOBFkA=; b=nrBrN4NA98Y/TMDzi67Vld3rPnlbTsjUKdB/9Wdg/U/7sj6x6TYnzZiL/BVEmyYtkR TgoqigbV3E9cmF1Oo3r/iMzrrH2JqouIlCBrqp6Es4Cgs60vKLTyhg2+lrlt7PVhbW3U TyJ/HG0Vr2NSbEfnVvzouj4SPl30Sv7Km3RwiwPCxv6OL5eLqNGF8WbTZ8OWkvT0vIpA FN9xbWn1XFb41pJiplNjjmlZhUl+8SNyOSEefNTlW7PMdx/GhVbUDxb0d9WQQRLMdP0m Ja4feLtV02egjgibonauOiZYkVwMSb3ly9uiolX1+6iY1XCZcb70I2HC8mJbbv4rHcLD QqLw== X-Gm-Message-State: AOAM532KfvtvnXpS6tAq6M/QMvYLkWRtd60vCuUvJsPDs7AqIxWgCFlB PDKTWIMUvn3MwoAKLE5nmnx1289lIzLBGTzcG8LYMQ== X-Google-Smtp-Source: ABdhPJxolcX3LP1ihKm2bbP1jeG3iVe2FxMR4/sEM/wfRoXpGz+Cy8beanyNCsFaGAsrhGiLe4hvXsKnV4wZ8uNC4IY= X-Received: by 2002:ac8:7247:: with SMTP id l7mr407755qtp.244.1603158910333; Mon, 19 Oct 2020 18:55:10 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Mon, 19 Oct 2020 19:54:58 -0600 Message-ID: Subject: Re: copyright notice question To: Rick Macklem Cc: "freebsd-current@FreeBSD.org" X-Rspamd-Queue-Id: 4CFcC43vLqz4W0W X-Spamd-Bar: - X-Spamd-Result: default: False [-1.76 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.96)[-0.956]; NEURAL_HAM_LONG(-1.00)[-1.004]; 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.20)[0.201]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::82a:from]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; 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]; MAILMAN_DEST(0.00)[freebsd-current] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2020 01:55:13 -0000 On Mon, Oct 19, 2020, 7:25 PM Rick Macklem wrote: > I'll admit I've hesitated to ask this for a long time, but I guess I have > to;-) > I've created two daemons for NFS-over-TLS, using the code in > /usr/src/usr.sbin/gssd/gssd.c as a starting point. > --> As such, I left the copyright notice from this file on the two files. > (As you can see, it is a 2 clause FreeBSD one, so the terms aren't > an issue.) > > What I am wondering is if I should be adding my name to it as an > additional author or something like that? > (I don't care, but it does seem a little weird that the copyright is held > by Isilon Inc, since I have no connection to them.) > Likely. If you changed a substantial amount, then yes. The rule of thumb is >50% is no brainer yes. Smaller percentages require more nuanced judgement as to whether the changes are substantial enough to create a new work. Chances are quite good you fall into one of those categories. Also, if you have replaced more than ~90% chances are good no original work remains. Again, a judgement call. There are more technical legal guidelines, but that would require a lawyer. My hunch is that unless this is something far more trivial than I then I'd add the notice, but retaining the old. Warnet Here's what it currently says: > /*- > * SPDX-License-Identifier: BSD-2-Clause-FreeBSD > * > * Copyright (c) 2008 Isilon Inc http://www.isilon.com/ > * Authors: Doug Rabson > * Developed with Red Inc: Alfred Perlstein > * > * Redistribution and use in source and binary forms, with or without > * modification, are permitted provided that the following conditions > * are met: > * 1. Redistributions of source code must retain the above copyright > * notice, this list of conditions and the following disclaimer. > * 2. Redistributions in binary form must reproduce the above copyright > * notice, this list of conditions and the following disclaimer in the > * documentation and/or other materials provided with the distribution. > * > * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND > * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE > * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR > PURPOSE > * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE > * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR > CONSEQUENTIAL > * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS > * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) > * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, > STRICT > * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY > WAY > * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF > * SUCH DAMAGE. > */ > > Thanks for any comments, rick > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@freebsd.org Tue Oct 20 07:15:22 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 35A874476F2 for ; Tue, 20 Oct 2020 07:15:22 +0000 (UTC) (envelope-from freebsd-current@lordsith.net) Received: from outbound.soverin.net (outbound.soverin.net [116.202.65.215]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4CFlJT0dNdz3ccg for ; Tue, 20 Oct 2020 07:15:20 +0000 (UTC) (envelope-from freebsd-current@lordsith.net) Received: from smtp.freedom.nl (unknown [10.10.3.36]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id DD5126084F for ; Tue, 20 Oct 2020 07:15:18 +0000 (UTC) Received: from smtp.freedom.nl (smtp.freedom.nl [116.202.65.211]) by soverin.net Date: Tue, 20 Oct 2020 07:15:16 +0000 From: marco To: freebsd-current@freebsd.org Subject: Re: Build failure Message-ID: <20201020071516.GA11920@freedom.nl> Reply-To: marco Mail-Followup-To: marco , freebsd-current@freebsd.org References: <20201003103630.b93bcef3cf5ea163cbd4b03d@bidouilliste.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: <20201003103630.b93bcef3cf5ea163cbd4b03d@bidouilliste.com> Organization: lordsith.net X-Operating-System: FreeBSD 13.0-CURRENT amd64 X-Unix: Use Unix or die X-Uptime: 10:45PM up 13 days, 2:33, 1 user, load averages: 4.26, 4.14, 4.14 X-Rspamd-Queue-Id: 4CFlJT0dNdz3ccg X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.44 / 15.00]; HAS_REPLYTO(0.00)[freebsd-current@lordsith.net]; ARC_NA(0.00)[]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:116.202.65.215]; 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)[]; RCVD_COUNT_THREE(0.00)[3]; DMARC_NA(0.00)[lordsith.net]; NEURAL_HAM_LONG(-1.01)[-1.013]; NEURAL_HAM_SHORT(-1.05)[-1.046]; NEURAL_HAM_MEDIUM(-0.98)[-0.980]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:116.202.0.0/16, country:DE]; RCVD_TLS_LAST(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current]; RCVD_IN_DNSWL_LOW(-0.10)[116.202.65.215:from] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2020 07:15:22 -0000 On Sat, Oct 03, 2020 at 10:36:30AM +0200, you (Emmanuel Vadot) sent the fol= lowing to [freebsd-current] : > On Fri, 2 Oct 2020 19:53:44 -0500 > Patrick McMunn wrote: >=20 > > I update the sources today and ran "make -j24 buildworld buildkernel > > KERNCONF=3DGENERIC-NODEBUG", and the build failed. I made sure to "make > > clean" and "make cleanworld" and try again, and I got the same result. > >=20 > > --=20 > > Patrick McMunn > >=20 > > - Learn more about the Catholic Faith: http://www.catholic.com/ > > - Pray with the Church: http://www.universalis.com/ >=20 > Hi, > You need to update your ports tree. > the drm-current-kmod ports install it's sources so the module will be > rebuilt when you build a kernel. > This works as long as no changes in base need changes in those sources > too. If there is needed changes in drm-kmod sources this unfortunatelly > fails to compile, not much we can do here. I checked out 05b104834ae7 (r366780) from https://cgit-beta.freebsd.org/src.git and ran a 'make -j4 builworld and mak= e -j4 buildkernel' for GENERIC-NODEBUG which also failed (buildworld was successfull). I did update the ports tree (portsnap fetch update) right before buildkernel and also have drm-current-kmod installed. My normal procedure of updating current using BEs (using WITH_MALLOC_PRODUCTION=3D in /etc/src.conf): make -j4 buildworld make -j4 buildkernel bectl create xxxxx bectl mount xxxxx /mnt make -j4 installkernel DESTDIR=3D/mnt mergemaster -Fp -D /mnt make -j4 installworld DESTDIR=3D/mnt mergemaster -Fi -D /mnt make -DBATCH_DELETE_OLD_FILES delete-old DESTDIR=3D/mnt make -DBATCH_DELETE_OLD_FILES delete-old-libs DESTDIR=3D/mnt (optional) bectl umount xxxxx bectl activate xxxxx shutdown -r +1 I do see there's an update to drm-current-kmod (g20201003) and I'm currently on g20200914 but I don't want to update in place in my current BE (not sure if this could solve the errors that are thrown). --- linux_backlight.o --- In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/src/linux_backlight.c:12: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/device.h:4: In file included from /usr/src/sys/compat/linuxkpi/common/include/linux/dev= ice.h:44: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/backlight.h:12: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/fb.h:10: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/pci.h:10: In file included from /usr/src/sys/compat/linuxkpi/common/include/linux/pci= =2Eh:52: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/dma-mapping.h:4: /usr/src/sys/compat/linuxkpi/common/include/linux/dma-mapping.h:116:10: err= or: incomplete definition of type 'struct device' if (!dev->dma_priv || !dma_supported(dev, dma_mask)) ~~~^ /usr/src/sys/sys/types.h:275:16: note: forward declaration of 'struct devic= e' typedef struct device *device_t; ^ In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/src/linux_backlight.c:12: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/device.h:4: In file included from /usr/src/sys/compat/linuxkpi/common/include/linux/dev= ice.h:44: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/backlight.h:12: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/fb.h:10: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/pci.h:10: /usr/src/sys/compat/linuxkpi/common/include/linux/pci.h:203:24: error: fiel= d has incomplete type 'struct device_driver' struct device_driver driver; ^ /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/i2c.h:= 201:9: note: forward declaration of 'struct device_driver' struct device_driver driver; ^ In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/src/linux_backlight.c:12: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/device.h:4: In file included from /usr/src/sys/compat/linuxkpi/common/include/linux/dev= ice.h:44: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/backlight.h:12: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/fb.h:10: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/pci.h:10: /usr/src/sys/compat/linuxkpi/common/include/linux/pci.h:233:17: error: fiel= d has incomplete type 'struct device' struct device dev; ^ /usr/src/sys/sys/types.h:275:16: note: forward declaration of 'struct devic= e' typedef struct device *device_t; ^ In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/src/linux_backlight.c:12: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/device.h:4: In file included from /usr/src/sys/compat/linuxkpi/common/include/linux/dev= ice.h:44: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/backlight.h:12: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/fb.h:10: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/pci.h:10: /usr/src/sys/compat/linuxkpi/common/include/linux/pci.h:331:9: error: impli= cit declaration of function 'dev_get_drvdata' is invalid in C99 [-Werror,-W= implicit-function-declaration] return dev_get_drvdata(&pdev->dev); ^ /usr/src/sys/compat/linuxkpi/common/include/linux/pci.h:338:2: error: impli= cit declaration of function 'dev_set_drvdata' is invalid in C99 [-Werror,-W= implicit-function-declaration] dev_set_drvdata(&pdev->dev, data); ^ In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/src/linux_backlight.c:12: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/device.h:4: In file included from /usr/src/sys/compat/linuxkpi/common/include/linux/dev= ice.h:44: /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/backli= ght.h:112:16: error: field has incomplete type 'struct device' struct device dev; ^ /usr/src/sys/sys/types.h:275:16: note: forward declaration of 'struct devic= e' typedef struct device *device_t; ^ In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/src/linux_backlight.c:12: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/device.h:4: In file included from /usr/src/sys/compat/linuxkpi/common/include/linux/dev= ice.h:44: /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/backli= ght.h:152:9: error: implicit declaration of function 'dev_get_drvdata' is i= nvalid in C99 [-Werror,-Wimplicit-function-declaration] return dev_get_drvdata(&bl_dev->dev); ^ In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/src/linux_backlight.c:12: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/device.h:4: /usr/src/sys/compat/linuxkpi/common/include/linux/device.h:212:1: error: st= atic declaration of 'dev_get_drvdata' follows non-static declaration dev_get_drvdata(const struct device *dev) ^ /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/i2c.h:= 243:9: note: previous implicit declaration is here return dev_get_drvdata(&dev->dev); ^ In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/src/linux_backlight.c:12: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/device.h:4: /usr/src/sys/compat/linuxkpi/common/include/linux/device.h:219:1: error: st= atic declaration of 'dev_set_drvdata' follows non-static declaration dev_set_drvdata(struct device *dev, void *data) ^ /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/i2c.h:= 249:2: note: previous implicit declaration is here dev_set_drvdata(&dev->dev, data); ^ In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/src/linux_backlight.c:12: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/device.h:4: /usr/src/sys/compat/linuxkpi/common/include/linux/device.h:438:1: error: st= atic declaration of 'device_unregister' follows non-static declaration device_unregister(struct device *dev) ^ /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/i2c.h:= 237:2: note: previous implicit declaration is here device_unregister(&client->dev); ^ --- linux_device.o --- cc -target x86_64-unknown-freebsd13.0 --sysroot=3D/usr/obj/usr/src/amd64.am= d64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe -fno-common '= -DKBUILD_MODNAME=3D"linuxkpi_gplv2"' -DLINUXKPI_VERSION=3D50000 -DCONFIG_DRM_AMDGPU_CIK -DCONFIG_DRM_AMDGPU_SI -DCONFIG_DRM_AMD_DC -DCONFIG= _DRM_AMD_DC_FBC -DCONFIG_DRM_AMD_POWERPLAY -DCONFIG_DRM_I915_ALPHA_SUPPORT = -DCONFIG_DRM_I915_FORCE_PROBE=3D'"*"' -DCONFIG_DRM_I915_CAPTURE_ERROR -DCON= FIG_DRM_I915_SPIN_REQUEST=3D5 -DCONFIG_DRM_I915_USERFAULT_AUTOSUSPEND=3D250= -DCONFIG_DRM_LOAD_EDID_FIRMWARE -DCONFIG_DRM_MIPI_DSI -DCONFIG_DRM_PANEL_O= RIENTATION_QUIRKS -DCONFIG_DRM_VMWGFX_FBCON -DCONFIG_DRM_FBDEV_EMULATION -D= CONFIG_DRM_FBDEV_OVERALLOC=3D100 -DCONFIG_DRM_LEGACY -DCONFIG_DRM_VM -DCONF= IG_ARCH_HAVE_NMI_SAFE_CMPXCHG -DCONFIG_BACKLIGHT_CLASS_DEVICE -DCONFIG_DMI = -DCONFIG_FB -DCONFIG_MTRR -DCONFIG_PCI -DCONFIG_PM -DCONFIG_SMP -DCONFIG_AC= PI -DCONFIG_ACPI_SLEEP -DCONFIG_AGP -DCONFIG_X86 -DCONFIG_X86_PAT -DCONFIG_= 64BIT -DCONFIG_AS_MOVNTDQA -DCONFIG_COMPAT -DCONFIG_X64_64 -DCONFIG_DRM_AMD= _DC_DCN1_0 -DCONFIG_DRM_AMD_DC_DCN1_01 -DCONFIG_DRM_AMD_DC_DCN2_0 -DCONFIG_= DRM_AMD_DC_DSC_SUPPORT -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE= -DKLD_TIED -nostdinc -I/usr/local/sys/modules/drm-current-kmod/include -I/usr/local/sys/modules/drm-current-kmod/linuxkpi/dummy/include -I/usr/loc= al/sys/modules/drm-current-kmod/linuxkpi/gplv2/include -I/usr/src/sys/compa= t/linuxkpi/common/include -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/us= r/src/amd64.amd64/sys/GENERIC-NODEBUG/opt_global.h -I. -I/usr/src/sys -I/us= r/src/sys/contrib/ck/include -fno-common -g -fno-omit-frame-pointer -mno-om= it-leaf-frame-pointer -fdebug-prefix-map=3D./machine=3D/usr/src/sys/amd64/i= nclude -fdebug-prefix-map=3D./x86=3D/usr/src/sys/x86/include -I/usr/obj/usr= /src/amd64.amd64/sys/GENERIC-NODEBUG -MD -MF.depend.linux_device.o -MT= linux_device.o -mcmodel=3Dkernel -mno-red-zone -mno-mmx -mno-sse -msoft-flo= at -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protecto= r -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -W= missing-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-tautological-compare -Wno-error-empt= y-body -Wno-error-parentheses-equality -Wno-error-unused-function -Wno-erro= r-pointer-sign -Wno-error-shift-negative-value -Wno-address-of-packed-membe= r -Wno-format-zero-length -Wno-pointer-arith -mno-aes -mno-avx -std=3Dis= o9899:1999 -c /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/src/li= nux_device.c -o linux_device.o --- linux_backlight.o --- /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/src/linux_backlight.= c:129:27: error: initializing 'struct backlight_device *' with an expressio= n of incompatible type 'void' struct backlight_device *bd =3D to_backlight_device(dev); ^ ~~~~~~~~~~~~~~~~~~~~~~~~ /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/src/linux_backlight.= c:138:27: error: initializing 'struct backlight_device *' with an expressio= n of incompatible type 'void' struct backlight_device *bd =3D to_backlight_device(dev); ^ ~~~~~~~~~~~~~~~~~~~~~~~~ /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/src/linux_backlight.= c:164:27: error: initializing 'struct backlight_device *' with an expressio= n of incompatible type 'void' struct backlight_device *bd =3D to_backlight_device(dev); ^ ~~~~~~~~~~~~~~~~~~~~~~~~ fatal error: too many errors emitted, stopping now [-ferror-limit=3D] 20 errors generated. *** [linux_backlight.o] Error code 1 make[4]: stopped in /usr/local/sys/modules/drm-current-kmod/linuxkpi --- linux_component.o --- In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/src/linux_component.c:1: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/component.h:18: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/device.h:4: In file included from /usr/src/sys/compat/linuxkpi/common/include/linux/dev= ice.h:44: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/backlight.h:12: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/fb.h:4: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/uapi/linux/fb.h:5: /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/i2c.h:= 140:16: error: field has incomplete type 'struct device' struct device dev; /* the adapter device */ ^ /usr/src/sys/sys/types.h:275:16: note: forward declaration of 'struct devic= e' typedef struct device *device_t; ^ In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/src/linux_component.c:1: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/component.h:18: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/device.h:4: In file included from /usr/src/sys/compat/linuxkpi/common/include/linux/dev= ice.h:44: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/backlight.h:12: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/fb.h:4: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/uapi/linux/fb.h:5: /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/i2c.h:= 166:16: error: field has incomplete type 'struct device' struct device dev; /* the device structure */ ^ /usr/src/sys/sys/types.h:275:16: note: forward declaration of 'struct devic= e' typedef struct device *device_t; ^ In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/src/linux_component.c:1: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/component.h:18: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/device.h:4: In file included from /usr/src/sys/compat/linuxkpi/common/include/linux/dev= ice.h:44: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/backlight.h:12: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/fb.h:4: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/uapi/linux/fb.h:5: /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/i2c.h:= 201:23: error: field has incomplete type 'struct device_driver' struct device_driver driver; ^ /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/i2c.h:= 201:9: note: forward declaration of 'struct device_driver' struct device_driver driver; ^ /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/i2c.h:= 237:2: error: implicit declaration of function 'device_unregister' is inval= id in C99 [-Werror,-Wimplicit-function-declaration] device_unregister(&client->dev); ^ /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/i2c.h:= 243:9: error: implicit declaration of function 'dev_get_drvdata' is invalid= in C99 [-Werror,-Wimplicit-function-declaration] return dev_get_drvdata(&dev->dev); ^ /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/i2c.h:= 249:2: error: implicit declaration of function 'dev_set_drvdata' is invalid= in C99 [-Werror,-Wimplicit-function-declaration] dev_set_drvdata(&dev->dev, data); ^ --- linux_compat.o --- In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/src/linux_compat.c:10: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/pci.h:10: In file included from /usr/src/sys/compat/linuxkpi/common/include/linux/pci= =2Eh:51: In file included from /usr/src/sys/compat/linuxkpi/common/include/linux/dma= pool.h:37: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/device.h:4: In file included from /usr/src/sys/compat/linuxkpi/common/include/linux/dev= ice.h:44: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/backlight.h:12: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/fb.h:4: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/uapi/linux/fb.h:5: /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/i2c.h:= 140:16: error: field has incomplete type 'struct device' struct device dev; /* the adapter device */ ^ /usr/src/sys/sys/types.h:275:16: note: forward declaration of 'struct devic= e' typedef struct device *device_t; ^ In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/src/linux_compat.c:10: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/pci.h:10: In file included from /usr/src/sys/compat/linuxkpi/common/include/linux/pci= =2Eh:51: In file included from /usr/src/sys/compat/linuxkpi/common/include/linux/dma= pool.h:37: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/device.h:4: In file included from /usr/src/sys/compat/linuxkpi/common/include/linux/dev= ice.h:44: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/backlight.h:12: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/fb.h:4: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/uapi/linux/fb.h:5: /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/i2c.h:= 166:16: error: field has incomplete type 'struct device' struct device dev; /* the device structure */ ^ /usr/src/sys/sys/types.h:275:16: note: forward declaration of 'struct devic= e' typedef struct device *device_t; ^ In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/src/linux_compat.c:10: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/pci.h:10: In file included from /usr/src/sys/compat/linuxkpi/common/include/linux/pci= =2Eh:51: In file included from /usr/src/sys/compat/linuxkpi/common/include/linux/dma= pool.h:37: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/device.h:4: In file included from /usr/src/sys/compat/linuxkpi/common/include/linux/dev= ice.h:44: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/backlight.h:12: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/fb.h:4: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/uapi/linux/fb.h:5: /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/i2c.h:= 201:23: error: field has incomplete type 'struct device_driver' struct device_driver driver; ^ /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/i2c.h:= 201:9: note: forward declaration of 'struct device_driver' struct device_driver driver; ^ --- linux_component.o --- In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/src/linux_component.c:1: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/component.h:18: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/device.h:4: In file included from /usr/src/sys/compat/linuxkpi/common/include/linux/dev= ice.h:44: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/backlight.h:12: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/fb.h:10: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/pci.h:10: In file included from /usr/src/sys/compat/linuxkpi/common/include/linux/pci= =2Eh:52: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/dma-mapping.h:4: --- linux_compat.o --- /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/i2c.h:= 237:2: error: implicit declaration of function 'device_unregister' is inval= id in C99 [-Werror,-Wimplicit-function-declaration] device_unregister(&client->dev); ^ --- linux_component.o --- /usr/src/sys/compat/linuxkpi/common/include/linux/dma-mapping.h:116:10: err= or: incomplete definition of type 'struct device' if (!dev->dma_priv || !dma_supported(dev, dma_mask)) ~~~^ /usr/src/sys/sys/types.h:275:16: note: forward declaration of 'struct devic= e' typedef struct device *device_t; ^ In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/src/linux_component.c:1: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/component.h:18: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/device.h:4: In file included from /usr/src/sys/compat/linuxkpi/common/include/linux/dev= ice.h:44: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/backlight.h:12: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/fb.h:10: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/pci.h:10: /usr/src/sys/compat/linuxkpi/common/include/linux/pci.h:203:24: error: fiel= d has incomplete type 'struct device_driver' struct device_driver driver; ^ /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/i2c.h:= 201:9: note: forward declaration of 'struct device_driver' struct device_driver driver; ^ In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/src/linux_component.c:1: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/component.h:18: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/device.h:4: In file included from /usr/src/sys/compat/linuxkpi/common/include/linux/dev= ice.h:44: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/backlight.h:12: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/fb.h:10: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/pci.h:10: /usr/src/sys/compat/linuxkpi/common/include/linux/pci.h:233:17: error: fiel= d has incomplete type 'struct device' struct device dev; ^ /usr/src/sys/sys/types.h:275:16: note: forward declaration of 'struct devic= e' typedef struct device *device_t; ^ In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/src/linux_component.c:1: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/component.h:18: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/device.h:4: In file included from /usr/src/sys/compat/linuxkpi/common/include/linux/dev= ice.h:44: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/backlight.h:12: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/fb.h:10: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/pci.h:10: /usr/src/sys/compat/linuxkpi/common/include/linux/pci.h:331:9: error: impli= cit declaration of function 'dev_get_drvdata' is invalid in C99 [-Werror,-W= implicit-function-declaration] return dev_get_drvdata(&pdev->dev); ^ /usr/src/sys/compat/linuxkpi/common/include/linux/pci.h:338:2: error: impli= cit declaration of function 'dev_set_drvdata' is invalid in C99 [-Werror,-W= implicit-function-declaration] dev_set_drvdata(&pdev->dev, data); ^ --- linux_compat.o --- /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/i2c.h:= 243:9: error: implicit declaration of function 'dev_get_drvdata' is invalid= in C99 [-Werror,-Wimplicit-function-declaration] return dev_get_drvdata(&dev->dev); ^ /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/i2c.h:= 249:2: error: implicit declaration of function 'dev_set_drvdata' is invalid= in C99 [-Werror,-Wimplicit-function-declaration] dev_set_drvdata(&dev->dev, data); ^ --- linux_component.o --- In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/src/linux_component.c:1: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/component.h:18: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/device.h:4: In file included from /usr/src/sys/compat/linuxkpi/common/include/linux/dev= ice.h:44: /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/backli= ght.h:112:16: error: field has incomplete type 'struct device' struct device dev; ^ /usr/src/sys/sys/types.h:275:16: note: forward declaration of 'struct devic= e' typedef struct device *device_t; ^ In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/src/linux_component.c:1: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/component.h:18: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/device.h:4: In file included from /usr/src/sys/compat/linuxkpi/common/include/linux/dev= ice.h:44: /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/backli= ght.h:152:9: error: implicit declaration of function 'dev_get_drvdata' is i= nvalid in C99 [-Werror,-Wimplicit-function-declaration] return dev_get_drvdata(&bl_dev->dev); ^ In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/src/linux_component.c:1: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/component.h:18: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/device.h:4: /usr/src/sys/compat/linuxkpi/common/include/linux/device.h:212:1: error: st= atic declaration of 'dev_get_drvdata' follows non-static declaration dev_get_drvdata(const struct device *dev) ^ /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/i2c.h:= 243:9: note: previous implicit declaration is here return dev_get_drvdata(&dev->dev); ^ In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/src/linux_component.c:1: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/component.h:18: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/device.h:4: /usr/src/sys/compat/linuxkpi/common/include/linux/device.h:219:1: error: st= atic declaration of 'dev_set_drvdata' follows non-static declaration dev_set_drvdata(struct device *dev, void *data) ^ /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/i2c.h:= 249:2: note: previous implicit declaration is here dev_set_drvdata(&dev->dev, data); ^ In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/src/linux_component.c:1: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/component.h:18: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/device.h:4: /usr/src/sys/compat/linuxkpi/common/include/linux/device.h:438:1: error: st= atic declaration of 'device_unregister' follows non-static declaration device_unregister(struct device *dev) ^ /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/i2c.h:= 237:2: note: previous implicit declaration is here device_unregister(&client->dev); ^ --- linux_compat.o --- In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/src/linux_compat.c:10: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/pci.h:10: In file included from /usr/src/sys/compat/linuxkpi/common/include/linux/pci= =2Eh:51: In file included from /usr/src/sys/compat/linuxkpi/common/include/linux/dma= pool.h:37: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/device.h:4: In file included from /usr/src/sys/compat/linuxkpi/common/include/linux/dev= ice.h:44: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/backlight.h:12: /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/fb.h:7= 30:55: error: declaration of 'struct pci_dev' will not be visible outside o= f this function [-Werror,-Wvisibility] extern int remove_conflicting_pci_framebuffers(struct pci_dev *pdev, int re= s_id, const char *name); ^ In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/src/linux_compat.c:10: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/pci.h:10: In file included from /usr/src/sys/compat/linuxkpi/common/include/linux/pci= =2Eh:51: In file included from /usr/src/sys/compat/linuxkpi/common/include/linux/dma= pool.h:37: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/device.h:4: In file included from /usr/src/sys/compat/linuxkpi/common/include/linux/dev= ice.h:44: /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/backli= ght.h:112:16: error: field has incomplete type 'struct device' struct device dev; ^ /usr/src/sys/sys/types.h:275:16: note: forward declaration of 'struct devic= e' typedef struct device *device_t; ^ --- linux_component.o --- 16 errors generated. --- linux_compat.o --- In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/src/linux_compat.c:10: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/pci.h:10: In file included from /usr/src/sys/compat/linuxkpi/common/include/linux/pci= =2Eh:51: In file included from /usr/src/sys/compat/linuxkpi/common/include/linux/dma= pool.h:37: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/device.h:4: In file included from /usr/src/sys/compat/linuxkpi/common/include/linux/dev= ice.h:44: /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/backli= ght.h:152:9: error: implicit declaration of function 'dev_get_drvdata' is i= nvalid in C99 [-Werror,-Wimplicit-function-declaration] return dev_get_drvdata(&bl_dev->dev); ^ In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/src/linux_compat.c:10: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/pci.h:10: In file included from /usr/src/sys/compat/linuxkpi/common/include/linux/pci= =2Eh:51: In file included from /usr/src/sys/compat/linuxkpi/common/include/linux/dma= pool.h:37: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/device.h:4: /usr/src/sys/compat/linuxkpi/common/include/linux/device.h:212:1: error: st= atic declaration of 'dev_get_drvdata' follows non-static declaration dev_get_drvdata(const struct device *dev) ^ /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/i2c.h:= 243:9: note: previous implicit declaration is here return dev_get_drvdata(&dev->dev); ^ In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/src/linux_compat.c:10: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/pci.h:10: In file included from /usr/src/sys/compat/linuxkpi/common/include/linux/pci= =2Eh:51: In file included from /usr/src/sys/compat/linuxkpi/common/include/linux/dma= pool.h:37: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/device.h:4: /usr/src/sys/compat/linuxkpi/common/include/linux/device.h:219:1: error: st= atic declaration of 'dev_set_drvdata' follows non-static declaration dev_set_drvdata(struct device *dev, void *data) ^ /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/i2c.h:= 249:2: note: previous implicit declaration is here dev_set_drvdata(&dev->dev, data); ^ --- linux_device.o --- In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/src/linux_device.c:1: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/device.h:4: In file included from /usr/src/sys/compat/linuxkpi/common/include/linux/dev= ice.h:44: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/backlight.h:12: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/fb.h:4: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/uapi/linux/fb.h:5: /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/i2c.h:= 140:16: error: field has incomplete type 'struct device' struct device dev; /* the adapter device */ ^ /usr/src/sys/sys/types.h:275:16: note: forward declaration of 'struct devic= e' typedef struct device *device_t; ^ In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/src/linux_device.c:1: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/device.h:4: In file included from /usr/src/sys/compat/linuxkpi/common/include/linux/dev= ice.h:44: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/backlight.h:12: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/fb.h:4: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/uapi/linux/fb.h:5: /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/i2c.h:= 166:16: error: field has incomplete type 'struct device' struct device dev; /* the device structure */ ^ /usr/src/sys/sys/types.h:275:16: note: forward declaration of 'struct devic= e' typedef struct device *device_t; ^ In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/src/linux_device.c:1: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/device.h:4: In file included from /usr/src/sys/compat/linuxkpi/common/include/linux/dev= ice.h:44: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/backlight.h:12: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/fb.h:4: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/uapi/linux/fb.h:5: /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/i2c.h:= 201:23: error: field has incomplete type 'struct device_driver' struct device_driver driver; ^ /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/i2c.h:= 201:9: note: forward declaration of 'struct device_driver' struct device_driver driver; ^ /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/i2c.h:= 237:2: error: implicit declaration of function 'device_unregister' is inval= id in C99 [-Werror,-Wimplicit-function-declaration] device_unregister(&client->dev); ^ --- linux_component.o --- *** [linux_component.o] Error code 1 make[4]: stopped in /usr/local/sys/modules/drm-current-kmod/linuxkpi --- linux_compat.o --- In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/src/linux_compat.c:10: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/pci.h:10: In file included from /usr/src/sys/compat/linuxkpi/common/include/linux/pci= =2Eh:51: In file included from /usr/src/sys/compat/linuxkpi/common/include/linux/dma= pool.h:37: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/device.h:4: /usr/src/sys/compat/linuxkpi/common/include/linux/device.h:438:1: error: st= atic declaration of 'device_unregister' follows non-static declaration device_unregister(struct device *dev) ^ /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/i2c.h:= 237:2: note: previous implicit declaration is here device_unregister(&client->dev); ^ --- linux_device.o --- /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/i2c.h:= 243:9: error: implicit declaration of function 'dev_get_drvdata' is invalid= in C99 [-Werror,-Wimplicit-function-declaration] return dev_get_drvdata(&dev->dev); ^ /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/i2c.h:= 249:2: error: implicit declaration of function 'dev_set_drvdata' is invalid= in C99 [-Werror,-Wimplicit-function-declaration] dev_set_drvdata(&dev->dev, data); ^ --- linux_compat.o --- 12 errors generated. *** [linux_compat.o] Error code 1 make[4]: stopped in /usr/local/sys/modules/drm-current-kmod/linuxkpi --- linux_device.o --- In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/src/linux_device.c:1: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/device.h:4: In file included from /usr/src/sys/compat/linuxkpi/common/include/linux/dev= ice.h:44: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/backlight.h:12: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/fb.h:10: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/pci.h:10: In file included from /usr/src/sys/compat/linuxkpi/common/include/linux/pci= =2Eh:52: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/dma-mapping.h:4: /usr/src/sys/compat/linuxkpi/common/include/linux/dma-mapping.h:116:10: err= or: incomplete definition of type 'struct device' if (!dev->dma_priv || !dma_supported(dev, dma_mask)) ~~~^ /usr/src/sys/sys/types.h:275:16: note: forward declaration of 'struct devic= e' typedef struct device *device_t; ^ In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/src/linux_device.c:1: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/device.h:4: In file included from /usr/src/sys/compat/linuxkpi/common/include/linux/dev= ice.h:44: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/backlight.h:12: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/fb.h:10: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/pci.h:10: /usr/src/sys/compat/linuxkpi/common/include/linux/pci.h:203:24: error: fiel= d has incomplete type 'struct device_driver' struct device_driver driver; ^ /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/i2c.h:= 201:9: note: forward declaration of 'struct device_driver' struct device_driver driver; ^ In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/src/linux_device.c:1: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/device.h:4: In file included from /usr/src/sys/compat/linuxkpi/common/include/linux/dev= ice.h:44: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/backlight.h:12: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/fb.h:10: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/pci.h:10: /usr/src/sys/compat/linuxkpi/common/include/linux/pci.h:233:17: error: fiel= d has incomplete type 'struct device' struct device dev; ^ /usr/src/sys/sys/types.h:275:16: note: forward declaration of 'struct devic= e' typedef struct device *device_t; ^ In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/src/linux_device.c:1: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/device.h:4: In file included from /usr/src/sys/compat/linuxkpi/common/include/linux/dev= ice.h:44: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/backlight.h:12: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/fb.h:10: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/pci.h:10: /usr/src/sys/compat/linuxkpi/common/include/linux/pci.h:331:9: error: impli= cit declaration of function 'dev_get_drvdata' is invalid in C99 [-Werror,-W= implicit-function-declaration] return dev_get_drvdata(&pdev->dev); ^ /usr/src/sys/compat/linuxkpi/common/include/linux/pci.h:338:2: error: impli= cit declaration of function 'dev_set_drvdata' is invalid in C99 [-Werror,-W= implicit-function-declaration] dev_set_drvdata(&pdev->dev, data); ^ In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/src/linux_device.c:1: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/device.h:4: In file included from /usr/src/sys/compat/linuxkpi/common/include/linux/dev= ice.h:44: /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/backli= ght.h:112:16: error: field has incomplete type 'struct device' struct device dev; ^ /usr/src/sys/sys/types.h:275:16: note: forward declaration of 'struct devic= e' typedef struct device *device_t; ^ In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/src/linux_device.c:1: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/device.h:4: In file included from /usr/src/sys/compat/linuxkpi/common/include/linux/dev= ice.h:44: /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/backli= ght.h:152:9: error: implicit declaration of function 'dev_get_drvdata' is i= nvalid in C99 [-Werror,-Wimplicit-function-declaration] return dev_get_drvdata(&bl_dev->dev); ^ In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/src/linux_device.c:1: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/device.h:4: /usr/src/sys/compat/linuxkpi/common/include/linux/device.h:212:1: error: st= atic declaration of 'dev_get_drvdata' follows non-static declaration dev_get_drvdata(const struct device *dev) ^ /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/i2c.h:= 243:9: note: previous implicit declaration is here return dev_get_drvdata(&dev->dev); ^ In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/src/linux_device.c:1: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/device.h:4: /usr/src/sys/compat/linuxkpi/common/include/linux/device.h:219:1: error: st= atic declaration of 'dev_set_drvdata' follows non-static declaration dev_set_drvdata(struct device *dev, void *data) ^ /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/i2c.h:= 249:2: note: previous implicit declaration is here dev_set_drvdata(&dev->dev, data); ^ In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/src/linux_device.c:1: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv= 2/include/linux/device.h:4: /usr/src/sys/compat/linuxkpi/common/include/linux/device.h:438:1: error: st= atic declaration of 'device_unregister' follows non-static declaration device_unregister(struct device *dev) ^ /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/i2c.h:= 237:2: note: previous implicit declaration is here device_unregister(&client->dev); ^ 16 errors generated. *** [linux_device.o] Error code 1 make[4]: stopped in /usr/local/sys/modules/drm-current-kmod/linuxkpi 4 errors make[4]: stopped in /usr/local/sys/modules/drm-current-kmod/linuxkpi *** [modules-all] Error code 2 make[2]: stopped in /usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG 1 error make[2]: stopped in /usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG --=20 Marco van Lienen -- FreeBSD enthusiast https://keybase.io/scarcry , GnuPG id: 8580E6CB "The Tuck Pendleton machine...zero defects." From owner-freebsd-current@freebsd.org Tue Oct 20 09:46:05 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5052B42B851 for ; Tue, 20 Oct 2020 09:46:05 +0000 (UTC) (envelope-from freebsd-current@lordsith.net) Received: from outbound.soverin.net (outbound.soverin.net [116.202.65.215]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4CFpfN2K5Rz45FN for ; Tue, 20 Oct 2020 09:46:03 +0000 (UTC) (envelope-from freebsd-current@lordsith.net) Received: from smtp.freedom.nl (unknown [10.10.3.36]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) by outbound.soverin.net (Postfix) with ESMTPS id 3A322608C4 for ; Tue, 20 Oct 2020 09:46:02 +0000 (UTC) Received: from smtp.freedom.nl (smtp.freedom.nl [116.202.65.211]) by soverin.net Date: Tue, 20 Oct 2020 09:46:00 +0000 From: marco To: freebsd-current@freebsd.org Subject: Re: Build failure Message-ID: <20201020094600.GA1631@freedom.nl> Reply-To: marco Mail-Followup-To: marco , freebsd-current@freebsd.org References: <20201003103630.b93bcef3cf5ea163cbd4b03d@bidouilliste.com> <20201020071516.GA11920@freedom.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201020071516.GA11920@freedom.nl> Organization: lordsith.net X-Operating-System: FreeBSD 13.0-CURRENT amd64 X-Unix: Use Unix or die X-Uptime: 9:39AM up 4 mins, 1 user, load averages: 0.04, 0.07, 0.03 X-Rspamd-Queue-Id: 4CFpfN2K5Rz45FN X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.52 / 15.00]; HAS_REPLYTO(0.00)[freebsd-current@lordsith.net]; ARC_NA(0.00)[]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:116.202.65.215]; 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)[]; RCVD_COUNT_THREE(0.00)[3]; DMARC_NA(0.00)[lordsith.net]; NEURAL_HAM_LONG(-1.01)[-1.014]; NEURAL_HAM_SHORT(-0.13)[-0.128]; NEURAL_HAM_MEDIUM(-0.98)[-0.979]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:24940, ipnet:116.202.0.0/16, country:DE]; RCVD_TLS_LAST(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current]; RCVD_IN_DNSWL_LOW(-0.10)[116.202.65.215:from] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2020 09:46:05 -0000 On Tue, Oct 20, 2020 at 07:15:16AM +0000, you (marco) sent the following to [freebsd-current] : > > > > I checked out 05b104834ae7 (r366780) from > https://cgit-beta.freebsd.org/src.git and ran a 'make -j4 builworld and make -j4 buildkernel' > for GENERIC-NODEBUG which also failed (buildworld was successfull). > I did update the ports tree (portsnap fetch update) right before > buildkernel and also have > drm-current-kmod installed. > > My normal procedure of updating current using BEs (using > WITH_MALLOC_PRODUCTION= in /etc/src.conf): > > make -j4 buildworld > make -j4 buildkernel > bectl create xxxxx > bectl mount xxxxx /mnt > make -j4 installkernel DESTDIR=/mnt > mergemaster -Fp -D /mnt > make -j4 installworld DESTDIR=/mnt > mergemaster -Fi -D /mnt > make -DBATCH_DELETE_OLD_FILES delete-old DESTDIR=/mnt > make -DBATCH_DELETE_OLD_FILES delete-old-libs DESTDIR=/mnt (optional) > bectl umount xxxxx > bectl activate xxxxx > shutdown -r +1 > > I do see there's an update to drm-current-kmod (g20201003) and I'm currently > on g20200914 but I don't want to > update in place in my current BE (not sure if this could solve the > errors that are thrown). > > --- linux_backlight.o --- > In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/src/linux_backlight.c:12: > In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/device.h:4: > In file included from /usr/src/sys/compat/linuxkpi/common/include/linux/device.h:44: > In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/backlight.h:12: > In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/fb.h:10: Managed to get this all sorted. I created a new BE based on r366252, mounted it and updated and upgraded pkg and all my packages (including drm-current-kmod) into that new BE. Booted to that BE and from there I did another buildkernel which succeeded. I hadn't run make cleanworld prior to the make buildkernel so still had that world built and proceeed from there. I'm now booted into my latest BE [~] uname -apKU FreeBSD harbinger 13.0-CURRENT FreeBSD 13.0-CURRENT #1 05b104834ae7-c253833(HE C-NODEBUG amd64 amd64 1300121 1300121 -- Marco van Lienen -- FreeBSD enthusiast https://keybase.io/scarcry , GnuPG id: 8580E6CB "The Tuck Pendleton machine...zero defects." From owner-freebsd-current@freebsd.org Tue Oct 20 14:23:16 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id C35034322F3 for ; Tue, 20 Oct 2020 14:23:16 +0000 (UTC) (envelope-from pen@lysator.liu.se) Received: from mail.lysator.liu.se (mail.lysator.liu.se [130.236.254.3]) (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 4CFwpC5z6Rz4NFc for ; Tue, 20 Oct 2020 14:23:15 +0000 (UTC) (envelope-from pen@lysator.liu.se) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id 189A240014 for ; Tue, 20 Oct 2020 16:23:12 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id 0260240021; Tue, 20 Oct 2020 16:23:11 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on bernadotte.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,AWL autolearn=disabled version=3.4.2 X-Spam-Score: -1.0 Received: from [IPv6:2001:6b0:17:f002:f117:32f:ba8e:c730] (unknown [IPv6:2001:6b0:17:f002:f117:32f:ba8e:c730]) (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 13AC940014; Tue, 20 Oct 2020 16:23:08 +0200 (CEST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Subject: Re: review of new mountd option disabling use of rpcbind From: Peter Eriksson In-Reply-To: Date: Tue, 20 Oct 2020 16:23:08 +0200 Cc: "freebsd-current@FreeBSD.org" Content-Transfer-Encoding: quoted-printable Message-Id: <7F127C98-8E05-45D7-A652-C29D656B4B56@lysator.liu.se> References: To: Rick Macklem X-Mailer: Apple Mail (2.3608.120.23.2.4) X-Virus-Scanned: ClamAV using ClamSMTP X-Rspamd-Queue-Id: 4CFwpC5z6Rz4NFc X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.32 / 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)[]; R_SPF_ALLOW(-0.20)[+a:mail.lysator.liu.se]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; ARC_NA(0.00)[]; NEURAL_HAM_LONG(-1.01)[-1.006]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[130.236.254.3:from]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[liu.se,none]; NEURAL_HAM_SHORT(-0.80)[-0.802]; NEURAL_HAM_MEDIUM(-1.01)[-1.012]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:2843, ipnet:130.236.0.0/16, country:SE]; RCVD_TLS_LAST(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2020 14:23:16 -0000 Suggestion:=20 Add a check for sysctl vfs.nfsd.server_min_nfsvers and if set to 4 or = higher - automatically enable the =E2=80=9C-R=E2=80=9D option. - Peter > On 20 Oct 2020, at 02:56, Rick Macklem wrote: >=20 > Hi, >=20 > I've put a patch up on phabricator that adds a new option to mountd > which disables use of rpcbind. This can be done for NFSv4 only = servers. > It appears that rpcbind is now considered a security risk by some. >=20 > I listed freqlabs@ as a reviewer, but if anyone else would like to = review > it, please do so. (Someone has reviewed the man page update already. > Thanks bcr@.) >=20 > It's D26746. >=20 > rick > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Tue Oct 20 14:37:27 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E70D94329D3 for ; Tue, 20 Oct 2020 14:37:27 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670067.outbound.protection.outlook.com [40.107.67.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CFx6Z4qQ3z4NSc for ; Tue, 20 Oct 2020 14:37:26 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KcPuLFnjLSAjPdEIe9FCSXgVLRv82A5KlBmMGHV/6HY0nDRi+b9uHTv6EWaFJKBmYlsI1ru/qsw3hGlQnUqAmRdIfNdRLz40vjZ7qfQLtBqvhApHeldmXW4vmwExVK4+NBFRh7WCQDMuaUZZHfe0xYX8HY/VUXmJ/ZU/TTvY9xphsdcznlMVCYBAHHkuUxf6Pgf/vwDqOirdyPO1WBElQXZ7e91bN7UlUbEt8JDGLgZwk3Z7dVrF0xH9Geu8jD9RNUdAnt32B2O+xuUlCpGw1vM9aVBN+A3WanJXFdXF+NqVdkLVsy73AYw/K8Y5OjGmA/Qr/BVk7e9to4yD/vMT6w== 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-SenderADCheck; bh=uMRXGxRJnrTS84qqzfygBNEHyZcj0F1VezSer3wh1EQ=; b=El8W4WKMmzjTP8/mDPsZBX1CIRxQUlIfeyVBuQauEgWk+e4a3GT3n/sFh/37oqnjFdJWD6fhSMl2oEJJjrxqTt9ucGQ65uk7bt9TjBmtcjE5FRge4orLeGgkA5bnqsOpA8p8A5MnAgoy8tL1tpMAY+43p6yZuu/Bw3WOoAqFfXrq4w1WuW2iNHrovsIzczqZ77sDfQbFEjMbqlq4k1eaiwHdIfBs45DwpyLiaUjqORm4cZSQMBP1GUZWu71s+jAy+fm3acuIVbsXVjI+YSFcrpZvBQ7kSx6hc60FL6eEcX72LhALDq9nB8OHc9FHGAniCgYiLEfSdS9DVRtDuKGgng== 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 Received: from YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:24::27) by YT1PR01MB2666.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:a::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.25; Tue, 20 Oct 2020 14:37:23 +0000 Received: from YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM ([fe80::687f:d85a:a0a3:bd20]) by YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM ([fe80::687f:d85a:a0a3:bd20%6]) with mapi id 15.20.3499.018; Tue, 20 Oct 2020 14:37:15 +0000 From: Rick Macklem To: Peter Eriksson CC: "freebsd-current@FreeBSD.org" Subject: Re: review of new mountd option disabling use of rpcbind Thread-Topic: review of new mountd option disabling use of rpcbind Thread-Index: AQHWpnttt8iTz/9j60mb0Wbz7GHaDqmgjBkAgAAAOOw= Date: Tue, 20 Oct 2020 14:37:14 +0000 Message-ID: References: , <7F127C98-8E05-45D7-A652-C29D656B4B56@lysator.liu.se> In-Reply-To: <7F127C98-8E05-45D7-A652-C29D656B4B56@lysator.liu.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 88007958-4f42-42fa-4c2e-08d87505a381 x-ms-traffictypediagnostic: YT1PR01MB2666: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 7kkYuBWngMSK2wDwEcpn0msf8eG5KjAzSY3ADVCKPospzV+AuZrXOAdOtDSMB6YwTu/2w2akV1gn8NMsnjNlx7EYc+ob80fgvD67lLlKrLKfxk+f9p94sf9zWKzJCr6XW0WkBGR6CMTR3Qh3FwJ3kQUaZB88s9N70mszrIzY+BZTzSjsrKLHI9kZmnJYPKtHn1nwraCs4zCGk4gNzVLlfxJ4sS2bjJLP1P9rlbMsXQxT5anChREo/SUxTZKWti7MXz/vsuocMfhR2Dx28+Hgt79XkYw6fQttMsEST2OQ4iVK8hGpvE7EIsQJ1buHTRhfphHQvJAvCbrN65a+fI+oLNJt/2e3DEm8kRZXp4jnjAsDiz//cu0463LMyAeHsB10d0RTLlOnFUqvFUPvRhfUrQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(396003)(39860400002)(136003)(346002)(376002)(366004)(8676002)(66556008)(2906002)(71200400001)(5660300002)(52536014)(8936002)(83380400001)(66946007)(64756008)(76116006)(66446008)(66476007)(478600001)(4326008)(786003)(316002)(296002)(6916009)(966005)(33656002)(55016002)(9686003)(53546011)(6506007)(86362001)(186003)(7696005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: mhK63QmoZNfMXi/EP0sfkWsRCNR/9OqiRhYPbK9d7VC3EQI0QDXBFqNgLa8X2naJ5NMsYJLoNTQt0YRZrmtNKkXN1GfrPGXhbhHKNdcgjlFtwm3OG48yoYeK5p32cg0hUdFzjwyIbynDQ0Thd/FeKrVl8c4ANTC5erNMvw1TNwSjApHjwgH6xxH4pixX2NBTl6ZAsq23dzHkYZHBJsMwaP/A824P7udVqnTdRp6eEx4VOHG1QJXGUF/s9Bqr1w+4FfmxloX5XQTRjzqNW5Q13JCV/Mi02X4suh0+tv21w5zWWVOkurEIpKKHnF9BQdARNCpgcSl1anIgFQK3prAr4vFhmJnWFadGuOW41qbd2USOz8s+CDviZWdnj9PivFjgem+xqmjbwwW3lyqJsQ+L1joe0scIwvSvExmBNDaTzFymF7Cb8hOkueRsCNeJzuZ7x5O3QlZhQWcIMXHYsHUGFp1XWHq/UxcltAZMgLsZ1Rx35nWm/L4OdS5dBUJiJpf40H26S5mpe3ZXmtH/S+pjeIQn07eySFlaxMDLXNmSiHv51na+cAOw31PmBnBIMZxSS/tANQy/RkrzDX8Gei3gsEcn9zi85KI83ySPEiMCRBbXzrltRya/wRVqHEpdo83qPOpYQUhsw/S4P5FsvJsMyVvCSx3EqQ6FGI3vTlMr7jHNxpuSW9Q3K2Y7/MEP+IXX2zh0tIOouuLRQpiU8C9LbQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 88007958-4f42-42fa-4c2e-08d87505a381 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Oct 2020 14:37:14.9922 (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: GxgGjOtTeGdo4eNNl+78wWcRUSiir6b+AOOVR/vMNs01qLGr4yZPBQ1pJEpnOn3mo2gKUeidglpiWYOKLn17FQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YT1PR01MB2666 X-Rspamd-Queue-Id: 4CFx6Z4qQ3z4NSc X-Spamd-Bar: ------ X-Spamd-Result: default: False [-6.49 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.001]; R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector1]; 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.02)[-1.016]; 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)[]; DKIM_TRACE(0.00)[uoguelph.ca:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[uoguelph.ca,none]; NEURAL_HAM_SHORT(-1.38)[-1.376]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.67.67:from]; 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]; MAILMAN_DEST(0.00)[freebsd-current]; RCVD_IN_DNSWL_LOW(-0.10)[40.107.67.67:from] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2020 14:37:28 -0000 Peter Eriksson wrote:=0A= > Suggestion:=0A= > Add a check for sysctl vfs.nfsd.server_min_nfsvers and if set to 4 or hig= her - =0A= > automatically enable the =93-R=94 option.=0A= I actually have patches to the /etc/rc.d scripts that both set=0A= vfs.nfsd.server_min_nfsvers=3D4 and the "-R" option.=0A= =0A= The reason I went with an explicit "-R" is that I thought having mountd=0A= magically stop registering with rpcbind might be considered a POLA=0A= violation.=0A= --> With the explicit "-R" option, it will only happen if the "-R" flag is= =0A= set or if nfsv4_server_only=3D"YES" is put in /etc/rc.conf (which is = new,=0A= so it will be expected to result in different behaviour).=0A= A second reason where the explicit "-R" might be preferred is:=0A= if the nfsd is a loadable module, it is loaded by mountd.=0A= However, to set the sysctl, it must be loaded before starting mountd.=0A= (This is done by the /etc/rc.d/mountd script, so it is not a big issue, but= =0A= might affect someone?)=0A= =0A= However, nfsd already chooses to not register when with rpcbind when=0A= vfs.nfsd.server_min_nfsvers, so I can also see an argument for doing=0A= what you suggest, since it is consistent with wat nfsd does.=0A= =0A= I don't have a strong opinion either way.=0A= What do others think?=0A= =0A= Thanks for the comment, rick=0A= =0A= - Peter=0A= =0A= =0A= > On 20 Oct 2020, at 02:56, Rick Macklem wrote:=0A= >=0A= > Hi,=0A= >=0A= > I've put a patch up on phabricator that adds a new option to mountd=0A= > which disables use of rpcbind. This can be done for NFSv4 only servers.= =0A= > It appears that rpcbind is now considered a security risk by some.=0A= >=0A= > I listed freqlabs@ as a reviewer, but if anyone else would like to review= =0A= > it, please do so. (Someone has reviewed the man page update already.=0A= > Thanks bcr@.)=0A= >=0A= > It's D26746.=0A= >=0A= > rick=0A= > _______________________________________________=0A= > freebsd-current@freebsd.org mailing list=0A= > https://lists.freebsd.org/mailman/listinfo/freebsd-current=0A= > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= "=0A= =0A= From owner-freebsd-current@freebsd.org Tue Oct 20 16:30:11 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 29BF44352A7; Tue, 20 Oct 2020 16:30:11 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-io1-xd41.google.com (mail-io1-xd41.google.com [IPv6:2607:f8b0:4864:20::d41]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CFzcf10Vhz4TkS; Tue, 20 Oct 2020 16:30:09 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-io1-xd41.google.com with SMTP id r9so1933133ioo.7; Tue, 20 Oct 2020 09:30:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=n9/mLNibkRyMFgkmn75fuNTABv/TFuMTIt4AZ2tHrQ4=; b=BotXb+nx8O/EaGte9bD3dFgGc1WDuZ9QLXwc7AQe6i3I0Qj/V0D0MFdyd/b9MskYjz qqBpCuvJ/fnv7zuz2wbTeEbjr2A7eA1wHZQQ6MEJ0LdXKYHfHnurwiBQFPEeEAFbOSVT 6doKdq/KJA8EHluaS2t4dxX7xeq+jWRqheQfVWoFJYZ+6ONGaSxWq/omMeqPwULmhiHt IbkNK6wVC4IPe0MgyLmBeLo2eASyvcrDMs2eh8zF7ppiNoczkuiDYbO4C0ASQmDEcfY1 XW3f4s1jynl4M5ESY8J8SbPP38N97Kgdbu0+J/DM9wpPtLgfhpgtBGdJvhLQ4u+KqjuW rZIQ== X-Gm-Message-State: AOAM532GeowNsd2Hyc7Tx8sJBIPDTIY3xi3IFoWrtUgwLCIeaTbCrv87 Ha2YQwMkvIFj+NAvPULLtx0oCBNZkp0= X-Google-Smtp-Source: ABdhPJzWFds/A+ilvfq2sewINcMpgTHv9wKTe3dKeOrLgNDI5K2OuO3dhJzBMBeKdCt1+QmY4KUpgw== X-Received: by 2002:a02:1349:: with SMTP id 70mr2835627jaz.130.1603211408493; Tue, 20 Oct 2020 09:30:08 -0700 (PDT) Received: from raichu (toroon0560w-lp130-01-174-88-77-103.dsl.bell.ca. [174.88.77.103]) by smtp.gmail.com with ESMTPSA id c9sm1951131iob.14.2020.10.20.09.30.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 Oct 2020 09:30:07 -0700 (PDT) Sender: Mark Johnston Date: Tue, 20 Oct 2020 12:30:05 -0400 From: Mark Johnston To: bob prohaska Cc: mmel@freebsd.org, freebsd-current@freebsd.org, freebsd-arm@freebsd.org Subject: Re: panic: non-current pmap 0xffffa00020eab8f0 on Rpi3 Message-ID: <20201020163005.GD46122@raichu> References: <20201006021029.GA13260@www.zefox.net> <20201006133743.GA96285@raichu> <20201019203954.GC46122@raichu> <20201019230909.GA66675@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201019230909.GA66675@www.zefox.net> X-Rspamd-Queue-Id: 4CFzcf10Vhz4TkS X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.31 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[text/plain]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-1.02)[-1.018]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; NEURAL_HAM_SHORT(-0.58)[-0.578]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::d41:from]; NEURAL_HAM_MEDIUM(-1.02)[-1.015]; 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]; MAILMAN_DEST(0.00)[freebsd-current,freebsd-arm] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2020 16:30:11 -0000 On Mon, Oct 19, 2020 at 04:09:09PM -0700, bob prohaska wrote: > On Mon, Oct 19, 2020 at 04:39:54PM -0400, Mark Johnston wrote: > > > > I think vmspace_exit() should issue a release fence with the cmpset and > > an acquire fence when handling the refcnt == 1 case, but I don't see why > > that would make a difference here. So, if you can test a debug patch, > > this one will yield a bit more debug info. If you can provide access to > > a vmcore and kernel debug symbols, that'd be even better. > > > > I haven't seen an invalid pmap panic since the report of October 5th. > Your patch applied cleanly on the Pi3 running HEAD at r366780M, > the M being due to patches supplied by Kyle Evans applied to > M sys/arm/broadcom/bcm2835/bcm2835_mbox.c > M sys/arm/broadcom/bcm2835/bcm2835_sdhci.c > M sys/arm/broadcom/bcm2835/bcm2835_vcbus.c > M sys/arm/broadcom/bcm2835/bcm2835_vcbus.h > > AIUI, they're something to do with DMA for peripherals. They've > caused no obvious trouble, if you anticipate conflicts let me know > and I'll remove them There should be no need to remove them. > I've never seen either a vmcore file or debug symbols on this machine. > A sequence of instructions to generate the data needed would be helpful. I set up a RPi3 to try and repro this and have so far managed to trigger it once using Peter Holm's stress2 suite, so I'll keep investigating. I hadn't configured a dump device, but I was able to confirm from DDB that PCPU_GET(curpmap) == &vmspace0->vm_pmap. For future reference, https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html has some info on configuring a dump device. For the RPi I'm just using a USB stick as the dump device. > Thanks for reading! > > bob prohaska > From owner-freebsd-current@freebsd.org Tue Oct 20 18:55:20 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id CA40E438989; Tue, 20 Oct 2020 18:55:20 +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 4CG2r82FxPz4dbS; Tue, 20 Oct 2020 18:55:20 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id 09KItWYO069517 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 20 Oct 2020 11:55:32 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id 09KItWW4069516; Tue, 20 Oct 2020 11:55:32 -0700 (PDT) (envelope-from fbsd) Date: Tue, 20 Oct 2020 11:55:30 -0700 From: bob prohaska To: Mark Johnston Cc: mmel@freebsd.org, freebsd-current@freebsd.org, freebsd-arm@freebsd.org Subject: Re: panic: non-current pmap 0xffffa00020eab8f0 on Rpi3 Message-ID: <20201020185530.GA69476@www.zefox.net> References: <20201006021029.GA13260@www.zefox.net> <20201006133743.GA96285@raichu> <20201019203954.GC46122@raichu> <20201019230909.GA66675@www.zefox.net> <20201020163005.GD46122@raichu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201020163005.GD46122@raichu> X-Rspamd-Queue-Id: 4CG2r82FxPz4dbS X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; ASN(0.00)[asn:7065, ipnet:50.1.16.0/20, country:US]; REPLY(-4.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Oct 2020 18:55:20 -0000 On Tue, Oct 20, 2020 at 12:30:05PM -0400, Mark Johnston wrote: > > I set up a RPi3 to try and repro this and have so far managed to trigger > it once using Peter Holm's stress2 suite, so I'll keep investigating. I > hadn't configured a dump device, but I was able to confirm from DDB that > PCPU_GET(curpmap) == &vmspace0->vm_pmap. > Is the invalid pmap fault related in any way to intensity of swap usage? That's easily adjusted using -j values building things like www/chromium. In the past, when I've reported crashes caused by stress2 I've observed a "that's inevitable" sort of response with some regularity. Panics when doing more normal things like make seem to stimulate greater interest. > For future reference, > https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html The pieces are all in place, but the machine doesn't seem to find core dumps when coming up after a crash. It does routinely issue "no core dumps found" during reboot, so it's looking. It it necessary to issue a dump command from inside the debugger? Thanks for writing! bob prohaska From owner-freebsd-current@freebsd.org Wed Oct 21 01:03:37 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0D17943E6C7 for ; Wed, 21 Oct 2020 01:03:37 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660060.outbound.protection.outlook.com [40.107.66.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CGC135x7Vz3SBy for ; Wed, 21 Oct 2020 01:03:35 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GbpoQVHoLCJY9AdehtxzOWxSypZkQqXJ7TZGlYB5DNYWu00+9wB0yn9ywAK7m8EI6EyPzIoqiHxlGZajoriECT8PjiCnu8yqiWJIk9RgHv7zkgo/BIGx0Ioq6gjllrwo+buP5e65yakpjVcyMDGRUeekJfzJlMjcuPoBsScCG/mPF4J5cbT21WM+z4tvZDhlOHmljeiBHK4H+QH+LsEYoCINkoYNiAO7N85xuSQ4YfbrxoAqBs6z+RKkY0JpbZD6dsb1Q2KUWU0UT6iYzJfmgsB6VjUFz2s6irCHZHWEMColdT+7k+b8S2h33BqyfAlm0bfFCtKa5JXlaR9WY5vH0g== 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-SenderADCheck; bh=ohhtWRvXoh5+Um5ICfEPv2XtQjjkYw9UxrcLi7jhPAA=; b=LjW6gQoP3IXOW8vL3yjdSU6L/O0u+6mlGm9JUi+AQCCSo3xX7MJVG0znACHSLZvL5GqaqMBsWGG14SR567bcd3imxxZLl7TAKzQQ/tFEG8FUX4e1/HiwXvTvQW/mTw+DlKxwptvHEGLs4W9bnWSEgOnDLCCSYNlyAw6fgdrcsUGyLuPzAgCZvjppnGXdtSQqAYK3PFPH1xvp2CIy0NKaUdALHAWjYUWFaeqsv3rxnDIkyJSDsoKHtiF8nOSMg/yROMIG1gUPAy/odgz9TJ8iBqn/4J33CFMYDtydQUhc0Gnzc+BN1XJY13+UW2RUIJJGSbyJ1Alwdp4UCf1Y2eYMyA== 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 Received: from YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:24::27) by YTXPR0101MB1645.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b00:4::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.20; Wed, 21 Oct 2020 01:03:33 +0000 Received: from YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM ([fe80::687f:d85a:a0a3:bd20]) by YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM ([fe80::687f:d85a:a0a3:bd20%6]) with mapi id 15.20.3499.018; Wed, 21 Oct 2020 01:03:25 +0000 From: Rick Macklem To: Warner Losh CC: "freebsd-current@FreeBSD.org" Subject: Re: copyright notice question Thread-Topic: copyright notice question Thread-Index: AQHWpn7fxoWEd2ZfUkuqrM0B3buK/KmfuwkAgAGBL08= Date: Wed, 21 Oct 2020 01:03:25 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 251599ca-064c-4b26-66fd-08d8755d1d14 x-ms-traffictypediagnostic: YTXPR0101MB1645: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: KA9nHe2ogm8KhRbl3nuc+Lir4EwoB0YaD0HASNzz5K4kHpo2eXwwQGoPeS2E5ZFUa0EMn6eagdjziI6Qz1/1Rw4iA10MYAVHKtXalCXn9Br0L3vcjT6JUaM0u0BcL0RhyII9XYiOptso2weWGEXRKAu6x+DRMcsTeJ9XsqrgidUvlpWJS2Q1NCAx/1UYXuSUcAy1K7haREhRgUXcuuEPuHM9vd7pfz8DECrwF3EzavFHSbAY/bA/16u04Z7GnSyD0ZDDnaCUWnCsiRCCtVHFmOvKYvIxBQU/IGmJHKYRQtTrkNImIfiAxNPe5powK7DtbvkDN48i9WFKTgrAl5Z6hU9BIYF/Q0PuphRVc7dX2rVevz8jHNy2o8my3iDWCRehh7hGANvBJXvvotsjkST0BQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(346002)(136003)(396003)(39850400004)(366004)(376002)(316002)(7696005)(4326008)(3480700007)(9686003)(786003)(19627235002)(478600001)(33656002)(71200400001)(966005)(52536014)(15650500001)(6916009)(186003)(55016002)(8936002)(7116003)(6506007)(76116006)(8676002)(91956017)(5660300002)(83380400001)(66476007)(66446008)(66556008)(64756008)(86362001)(2906002)(66946007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 8uqYvSV5tIOB0vat0dTDyu3BNABdmQd/qlLd/7I+ukMjXilt9cA6Fh+xRmehKfoU+2vkuzDAy894ZKLVGD4YuX6SHwjFckScIuQgnV2Rg/GBsgA2jIsGub0nvslZvP/cVRTT5siv65ldHiU3SPpLaCdpGlju2QTVhfLfitQ1kOrBgMNY9WhdKGu/n+N9sGX+WexyzQl1IDFD9OrGjcE0ZY3LoPIVZHR9gdwXBYj77UN/vwmTiGgLfE/RqXQR5OY6cShwfmtbnJaknq7dohXt11XjY4Zw7L507Gi+b68vco4zYJ9bXQWSNyT8hf2pEaa6KXj5fnscem1rUFaGFOSDJLKwieY6kvLowFN3XkKSMHCfytg2oCf+KOz6mg5FCR7G/zIChXrzyTuPlm1bcI8mp3BmWoyL5bG94F+FaoQ6TNIqtmDLGNG811YPTwPmnwuTlh4leC0y5xvBmOzOHF2U2oEOlPebXPgs/94meVhwzCU3fFa8y02J493fIDT8iktPZe/IgttaVhtjnZDO1PYKgrvznxMiU2jymPXCSc4Mb9utwIVsmN5xPzC9lnv1XhLvYQbdTNSSgLXsqAnRN6/4phIl7sp1eWdXagViWgHb7Pq3/0zzi/R0WicVkoB51053A6Zh2l/OYQpXIYBkqpRx9ejRNqgCRHBP/D/Eugf94AHc9faD5BOQbFjAi4qaDHahCnaffEfkBm1YqVErFafSWg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 251599ca-064c-4b26-66fd-08d8755d1d14 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Oct 2020 01:03:25.2600 (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: 7qoAAcr5BzGDRH1ndiX8q718B2LAShDSeUqaWh13v+EFY+y4AswiEs4TreezX9vaJ8djpunpITkaeKRO+KS/3w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR0101MB1645 X-Rspamd-Queue-Id: 4CGC135x7Vz3SBy X-Spamd-Bar: ------ X-Spamd-Result: default: False [-6.07 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.003]; R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector1]; 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.02)[-1.016]; 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)[]; DKIM_TRACE(0.00)[uoguelph.ca:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[40.107.66.60:from]; NEURAL_HAM_SHORT(-1.05)[-1.054]; DMARC_POLICY_ALLOW(-0.50)[uoguelph.ca,none]; 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]; MAILMAN_DEST(0.00)[freebsd-current]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.66.60:from] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2020 01:03:37 -0000 Warner Losh wrote:=0A= >On Mon, Oct 19, 2020, 7:25 PM Rick Macklem > wrote:=0A= >>I'll admit I've hesitated to ask this for a long time, but I guess I have= to;-)=0A= >>I've created two daemons for NFS-over-TLS, using the code in=0A= >>/usr/src/usr.sbin/gssd/gssd.c as a starting point.=0A= >>--> As such, I left the copyright notice from this file on the two files.= =0A= >> (As you can see, it is a 2 clause FreeBSD one, so the terms aren't= =0A= >> an issue.)=0A= >>=0A= >>What I am wondering is if I should be adding my name to it as an=0A= >>additional author or something like that?=0A= >>(I don't care, but it does seem a little weird that the copyright is held= =0A= >> by Isilon Inc, since I have no connection to them.)=0A= >>=0A= >Likely. If you changed a substantial amount, then yes. The rule of thumb i= s >50%=0A= > is no brainer yes. Smaller percentages require more nuanced judgement as = to whether the changes are substantial enough to create a new work. Chances= are=0A= > quite good you fall into one of those categories. Also, if you have repla= ced more =0A= >than ~90% chances are good no original work remains. Again, a judgement ca= ll. =0A= >There are more technical legal guidelines, but that would require a lawyer= .=0A= >=0A= >My hunch is that unless this is something far more trivial than I then I'd= add the=0A= > notice, but retaining the old.=0A= Well, I'd guess it's somewhere in the 50->90% category.=0A= Would just adding a comment below the current copyright notice like:=0A= /*=0A= * Extensively modified from /usr/src/usr.sbin/gssd.c for RPC-over-TLS=0A= * by Rick Macklem.=0A= */=0A= be sufficient for the project, or should I put a second copyright notice=0A= on it with my name on it? (This will seem odd, since it will have the same= =0A= terms as the extant one, but if that is what is appropriate for the project= ..)=0A= =0A= It is my understanding (I'm obviously not a lawyer, clearly indicated by th= e=0A= size of my bank account;-) that a copyright notice can only be changed by= =0A= the holder (or with their express permission), but an additional copyright= =0A= notice can be attached to the work to cover the re-write.=0A= Is this correct? (All amateur lawyers, feel free to respond;-)=0A= =0A= Thanks for your comments, rick=0A= =0A= Warnet=0A= =0A= =0A= Here's what it currently says:=0A= /*-=0A= * SPDX-License-Identifier: BSD-2-Clause-FreeBSD=0A= *=0A= * Copyright (c) 2008 Isilon Inc http://www.isilon.com/=0A= * Authors: Doug Rabson >=0A= * Developed with Red Inc: Alfred Perlstein >=0A= *=0A= * Redistribution and use in source and binary forms, with or without=0A= * modification, are permitted provided that the following conditions=0A= * are met:=0A= * 1. Redistributions of source code must retain the above copyright=0A= * notice, this list of conditions and the following disclaimer.=0A= * 2. Redistributions in binary form must reproduce the above copyright=0A= * notice, this list of conditions and the following disclaimer in the= =0A= * documentation and/or other materials provided with the distribution.= =0A= *=0A= * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND= =0A= * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE=0A= * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPO= SE=0A= * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE= =0A= * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTI= AL=0A= * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS= =0A= * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)=0A= * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRI= CT=0A= * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WA= Y=0A= * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF= =0A= * SUCH DAMAGE.=0A= */=0A= =0A= Thanks for any comments, rick=0A= _______________________________________________=0A= freebsd-current@freebsd.org mailing lis= t=0A= https://lists.freebsd.org/mailman/listinfo/freebsd-current=0A= To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"=0A= From owner-freebsd-current@freebsd.org Wed Oct 21 07:56:16 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id AB3F0446003 for ; Wed, 21 Oct 2020 07:56:16 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-ot1-x32f.google.com (mail-ot1-x32f.google.com [IPv6:2607:f8b0: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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CGN9C52nYz41hS for ; Wed, 21 Oct 2020 07:56:15 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: by mail-ot1-x32f.google.com with SMTP id f10so1057782otb.6 for ; Wed, 21 Oct 2020 00:56:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vjig0pdplq+6vA9bCd/tj3qKF06+HmbcyyjYV2IU+5E=; b=fUxKS7dyDD/QKtW5yzBMhn2mCAVsYN3cg1MtHdTx+E6vujsH6ktW1oXu2f/JWVGDaD 26E6Ldyxg+GmA1ouSVoFYZnJ8iqPGCNxFEaSqhbRxyUYG8fDwIE8XgsQtvXfRpa7ap31 KI+ykfSppvoLkwYDGxnAIKuKbUtnQAQERbIOCMDohceyN65rFgW+n5AY0d7PwBGygSme HnMa5LmqZX04OCFfn1rPqP/TbW4LUOdG+pClzIedN5M/uW40DK/ys/xI/enu55COzXqL oPGW8vxYpmsTntpBWiUMXYBPZS6u2gw9CjsfLOBd+tOpU7gSqMV0FejnH8n7VHz/sB9F ZGOA== X-Gm-Message-State: AOAM532UfV4vKn29mv4GcH8oI5Ha7A6Zs7g1g3OjRWaoRqu23k2xIzT9 NfiCdtEFdOqlTl3Hq6YtAheJpnGAVVlaMV9Pg98= X-Google-Smtp-Source: ABdhPJzlFeitgnyDDrHLnFXJobBJJs/mmfaqtIHj9uf/siSsahKTOw0lzh7LV5ajrHeD4JIw/wMQsLeE1L8K8/hjvXs= X-Received: by 2002:a9d:7f09:: with SMTP id j9mr1623112otq.184.1603266972748; Wed, 21 Oct 2020 00:56:12 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Mehmet Erol Sanliturk Date: Wed, 21 Oct 2020 10:55:35 +0300 Message-ID: Subject: Re: copyright notice question To: Rick Macklem Cc: Warner Losh , "freebsd-current@FreeBSD.org" X-Rspamd-Queue-Id: 4CGN9C52nYz41hS X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.61 / 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]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.60)[-0.601]; 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.002]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.01)[-1.006]; 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::32f:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2020 07:56:16 -0000 On Wed, Oct 21, 2020 at 4:04 AM Rick Macklem wrote: > Warner Losh wrote: > >On Mon, Oct 19, 2020, 7:25 PM Rick Macklem rmacklem@uoguelph.ca>> wrote: > >>I'll admit I've hesitated to ask this for a long time, but I guess I > have to;-) > >>I've created two daemons for NFS-over-TLS, using the code in > >>/usr/src/usr.sbin/gssd/gssd.c as a starting point. > >>--> As such, I left the copyright notice from this file on the two files. > >> (As you can see, it is a 2 clause FreeBSD one, so the terms aren't > >> an issue.) > >> > >>What I am wondering is if I should be adding my name to it as an > >>additional author or something like that? > >>(I don't care, but it does seem a little weird that the copyright is held > >> by Isilon Inc, since I have no connection to them.) > >> > >Likely. If you changed a substantial amount, then yes. The rule of thumb > is >50% > > is no brainer yes. Smaller percentages require more nuanced judgement as > to whether the changes are substantial enough to create a new work. Chances > are > > quite good you fall into one of those categories. Also, if you have > replaced more > >than ~90% chances are good no original work remains. Again, a judgement > call. > >There are more technical legal guidelines, but that would require a > lawyer. > > > >My hunch is that unless this is something far more trivial than I then > I'd add the > > notice, but retaining the old. > Well, I'd guess it's somewhere in the 50->90% category. > Would just adding a comment below the current copyright notice like: > /* > * Extensively modified from /usr/src/usr.sbin/gssd.c for RPC-over-TLS > * by Rick Macklem. > */ > be sufficient for the project, or should I put a second copyright notice > on it with my name on it? (This will seem odd, since it will have the same > terms as the extant one, but if that is what is appropriate for the > project..) > > It is my understanding (I'm obviously not a lawyer, clearly indicated by > the > size of my bank account;-) that a copyright notice can only be changed by > the holder (or with their express permission), but an additional copyright > notice can be attached to the work to cover the re-write. > Is this correct? (All amateur lawyers, feel free to respond;-) > > Thanks for your comments, rick > > Warnet > > > Here's what it currently says: > /*- > * SPDX-License-Identifier: BSD-2-Clause-FreeBSD > * > * Copyright (c) 2008 Isilon Inc http://www.isilon.com/ > * Authors: Doug Rabson > > * Developed with Red Inc: Alfred Perlstein alfred@freebsd.org>> > * > * Redistribution and use in source and binary forms, with or without > * modification, are permitted provided that the following conditions > * are met: > * 1. Redistributions of source code must retain the above copyright > * notice, this list of conditions and the following disclaimer. > * 2. Redistributions in binary form must reproduce the above copyright > * notice, this list of conditions and the following disclaimer in the > * documentation and/or other materials provided with the distribution. > * > * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND > * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE > * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR > PURPOSE > * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE > * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR > CONSEQUENTIAL > * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS > * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) > * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, > STRICT > * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY > WAY > * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF > * SUCH DAMAGE. > */ > > Thanks for any comments, rick > _______________________________________________ > > My opinion is as follows : At the top of the related sources I would include a message ( approximately ) as follows : " After svn ( or git ) modification number(s) ... ( including ) I have made substantial ( or significant ) modifications ( or improvements ) . The copyright of these modifications with the present license listed below are belong to Rick Macklem , starting from date ..... ( Rick Macklem ... an approximately fixed address ... ) " Each contributor may append such notifications listed on the topmost part . When a person reads such sources , she/he very easily understands its modification and copyright status without any doubt . Mehmet Erol Sanliturk From owner-freebsd-current@freebsd.org Wed Oct 21 16:07:55 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id BEEB244F3CA; Wed, 21 Oct 2020 16:07:55 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qk1-x744.google.com (mail-qk1-x744.google.com [IPv6:2607:f8b0:4864:20::744]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CGb4W1Yvtz4TcP; Wed, 21 Oct 2020 16:07:54 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qk1-x744.google.com with SMTP id q199so2485261qke.10; Wed, 21 Oct 2020 09:07:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=QGC+ixlMMLfVL7wRDp7w7Oz3gTx7eWRWfVASP2SOaTo=; b=Fm1W+jy0TTI5VK9TpfabBsukWRMhVnXlEbJ5u7/4kjSPsUyyUQESHxiSOKgJWMMxYA X4dY8HHcYCMd3ytT8k3FyRh47g07XWI3LgcpkqssxHSUMJGbwcF14VGYDOoHYig6BZjh /mEid4ayA9/Crnz/xfSofv4HzvHWyI1UafuKihBlA9BPVRxw15KgGMjbMWg+9pZSjayq 5mNgaTm7eo4cUIhDMECpJIJmtF2xQ4XK1K9JwwrbtAyf6bwWNcylZjZDoiDTG9tVUr5f XDRhNqWUJILPdvY0oM9QFn5uloIL43kxhcexGlf504XRDvSA83ph3Eex0gzJUclfXYrI LkgQ== X-Gm-Message-State: AOAM533oxMO7tuZg0SrYR2441+zXzYk6gl2vYw8+rn4mmzYDucYuuyY6 /+2NBH2UX3tWZGWPtgtPPfKglOckf+A= X-Google-Smtp-Source: ABdhPJz53pgJfXX6Zlhg0/vQv45Z8c3LxlwLfhEoQ4q0NsPepGCgIUh19APmmnV6A11GaZo4cCncgg== X-Received: by 2002:a37:988:: with SMTP id 130mr3792711qkj.313.1603296474209; Wed, 21 Oct 2020 09:07:54 -0700 (PDT) Received: from raichu (toroon0560w-lp130-01-174-88-77-103.dsl.bell.ca. [174.88.77.103]) by smtp.gmail.com with ESMTPSA id l19sm1545486qkk.99.2020.10.21.09.07.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Oct 2020 09:07:53 -0700 (PDT) Sender: Mark Johnston Date: Wed, 21 Oct 2020 12:07:48 -0400 From: Mark Johnston To: bob prohaska Cc: mmel@freebsd.org, freebsd-current@freebsd.org, freebsd-arm@freebsd.org Subject: Re: panic: non-current pmap 0xffffa00020eab8f0 on Rpi3 Message-ID: <20201021160748.GA17318@raichu> References: <20201006021029.GA13260@www.zefox.net> <20201006133743.GA96285@raichu> <20201019203954.GC46122@raichu> <20201019230909.GA66675@www.zefox.net> <20201020163005.GD46122@raichu> <20201020185530.GA69476@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201020185530.GA69476@www.zefox.net> X-Rspamd-Queue-Id: 4CGb4W1Yvtz4TcP X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.48 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; NEURAL_HAM_LONG(-0.99)[-0.986]; MIME_GOOD(-0.10)[text/plain]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_NA(0.00)[freebsd.org]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; NEURAL_HAM_SHORT(-0.78)[-0.775]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::744:from]; NEURAL_HAM_MEDIUM(-1.01)[-1.014]; 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]; MAILMAN_DEST(0.00)[freebsd-current,freebsd-arm] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2020 16:07:55 -0000 On Tue, Oct 20, 2020 at 11:55:30AM -0700, bob prohaska wrote: > On Tue, Oct 20, 2020 at 12:30:05PM -0400, Mark Johnston wrote: > > > > I set up a RPi3 to try and repro this and have so far managed to trigger > > it once using Peter Holm's stress2 suite, so I'll keep investigating. I > > hadn't configured a dump device, but I was able to confirm from DDB that > > PCPU_GET(curpmap) == &vmspace0->vm_pmap. > > > > Is the invalid pmap fault related in any way to intensity of swap usage? > That's easily adjusted using -j values building things like www/chromium. > In the past, when I've reported crashes caused by stress2 I've observed > a "that's inevitable" sort of response with some regularity. Panics when > doing more normal things like make seem to stimulate greater interest. I don't think there is any direct relation with swap usage. The one time I've reproduced this so far there was no swapping involved. I've noticed that stress2 runs on the RPi3 tend to abort or hang in various ways, but so far haven't seen any panics except the one we're chasing. > > For future reference, > > https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html > > The pieces are all in place, but the machine doesn't seem to find core > dumps when coming up after a crash. It does routinely issue "no core dumps > found" during reboot, so it's looking. It it necessary to issue a dump > command from inside the debugger? It depends: if debug.debugger_on_panic is set to 1, you will indeed need to issue a "dump" command from DDB before rebooting. Otherwise the system should automatically dump and reboot. You'll need to have "dumpdev" configured in rc.conf in order for vmcores to be recovered automatically. Otherwise savecore(8) can be run manually. > Thanks for writing! > > bob prohaska > From owner-freebsd-current@freebsd.org Wed Oct 21 22:07:22 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E9BCF42FB82 for ; Wed, 21 Oct 2020 22:07:22 +0000 (UTC) (envelope-from debdrup@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 4CGl3G5X0cz3c1B for ; Wed, 21 Oct 2020 22:07:22 +0000 (UTC) (envelope-from debdrup@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id B78B842FB1E; Wed, 21 Oct 2020 22:07:22 +0000 (UTC) Delivered-To: current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B69F842FB1D; Wed, 21 Oct 2020 22:07:22 +0000 (UTC) (envelope-from debdrup@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 "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CGl3G4mnNz3cGj; Wed, 21 Oct 2020 22:07:22 +0000 (UTC) (envelope-from debdrup@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1471) id 9593F1955C; Wed, 21 Oct 2020 22:07:22 +0000 (UTC) Date: Thu, 22 Oct 2020 00:07:20 +0200 From: Daniel Ebdrup Jensen To: hackers@freebsd.org Cc: current@freebsd.org, stable@freebsd.org Subject: FreeBSD Quarterly Status Report - Third Quarter 2020 Message-ID: <20201021220720.mehxu5cjqcysztzt@nerd-thinkpad.local> Mail-Followup-To: Daniel Ebdrup Jensen , hackers@freebsd.org, current@freebsd.org, stable@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="u3hngvn2nte45ec7" Content-Disposition: inline ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1603318042; h=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=3k/7cOhY3ykWXAyGhMTeKCk5//0GlnJUC6835QYUvCM=; b=tV4iX0Bh9k9knz+fYfW+3x38mBPBxj/JzDj+DL+rg5qSkthXXMM6CuQSpskV138n2micq0 Orxnw4seKGmsVBDazgg2g0pkeL9aFbSsNf8lVXx8zEW6/ZIdn/NUH+KveAAndfRer0jTry EX8KcxHaJ9RWU1doab+ZthtX72E9Kf48oDxiqiIyDRcp/SOuQnknPvpx3HJToUGTtQ/xgd Psqace19HJHcZ3LO0vlNF74fcYvT9AU+GpcLdHHalVo6++OaUwAO1cITLjkCZLVK6V+Q+a u6T3Kda9a+BNoSKq3CC9ZOrBai01C5BqI6KRegPf+zwAjdxww/LOPDRo2opH8Q== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1603318042; a=rsa-sha256; cv=none; b=J5KDIiI0oNlp9pCfuZG9KDMUnxdRqC93yyV7S5eAEzBvRnFwnwaEgBGBxCbDl9WHw2mU6e dHHDA2VSbDeG2vmvNQEZ4ppecfili8F+9ek7XtrFOB2kkuGGBwkFLfzGF5zj0QIShIm0hF MuHYtAbSmS+o7D91yU3Td2rIfDi0krTOrpM0nrO0y/F/fBBW7OgHPORgo3aMQeb+abx7cY 0tN7z/4kR2UHpxWu96St1GDe7K1faUsF30A7K5lGoei6kulk7Q/5VTNhUZPqmR1XDDcvqO Ij0Ymk5pBrLWV4uVe67nsKP1+9v1mcvjDHg/7TgyN+n8mEE+zYbs2on+fq6kCQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2020 22:07:23 -0000 --u3hngvn2nte45ec7 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable FreeBSD Project Quarterly Status Report - Third Quarter 2020 Introduction This report covers FreeBSD related projects for the period between July and September, and is the third of four planned reports for 2020. This quarter brings a good mix of additions and changes to the FreeBSD Project and community, from a diverse number of teams and people covering everything from architectures, continuous integration, wireless networking and drivers, over drm, desktop and third-party project work, as well as several team reports, along with many other interesting subjects too numerous to mention. As the world is still affected by the epidemic, we hope that this report can also serve as a good reminder that there is good work that can be done by people working together, even if we're apart. We hope you'll be as interested in reading it, as we've been in making it. Daniel Ebdrup Jensen, on behalf of the quarterly team. __________________________________________________________________ FreeBSD Team Reports * FreeBSD Foundation * FreeBSD Release Engineering Team * Cluster Administration Team * Continuous Integration * Ports Collection * FreeBSD Office team - 3rd quarter 2020 report * FreeBSD Graphics Team status report Projects * FreeBSD on Microsoft HyperV and Azure * Building FreeBSD on non-FreeBSD hosts * Git Migration Working Group * Linux compatibility layer update * LLDB Debugger Improvements * Lua usage in FreeBSD * NFS over TLS implementation * syzkaller on FreeBSD Kernel * DRM Drivers Update * DTS Update * DesignWare Ethernet adapter driver improvements * Google Summer of Code'20 Project - eBPF XDP Hooks * ENA FreeBSD Driver Update * IPSec Extended Sequence Number (ESN) support * NXP ARM64 SoC support * Addition of PowerPC64LE Architecture * ure - USB 3.0 Gigabit Ethernet Driver update * Stateless hardware offloads for VXLANs * Wireless updates * ZSTD Compression in ZFS Architectures * CheriBSD 2020 Q3 * FreeBSD/RISC-V Project Ports * Update to grub-bhyve * KDE on FreeBSD Documentation * DOCNG on FreeBSD Third-Party Projects * Potluck - Flavour & Image Repository for pot __________________________________________________________________ FreeBSD Team Reports Entries from the various official and semi-official teams, as found in the Administration Page. FreeBSD Foundation 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. Funding comes from individual and corporate donations and is used to fund and manage software development projects, conferences and developer summits, and provide travel grants to FreeBSD contributors. The Foundation purchases and supports hardware to improve and maintain FreeBSD infrastructure and provides resources to improve security, quality assurance, and release engineering efforts; publishes marketing material to promote, educate, and advocate for the FreeBSD Project; facilitates collaboration between commercial vendors and FreeBSD developers; and finally, represents the FreeBSD Project in executing contracts, license agreements, and other legal arrangements that require a recognized legal entity. Here are some highlights of what we did to help FreeBSD last quarter: COVID-19 Impact to the Foundation Like other organizations, we put policies in place for all of our staff members to work from home. We also put a temporary ban on travel for staff members. We are continuing our work supporting the community and Project, but some of our work and responses may be delayed because of changes in some of our priorities and the impact of limited childcare for a few of our staff members. Partnerships and Commercial User Support We help facilitate collaboration between commercial users and FreeBSD developers. We also meet with companies to discuss their needs and bring that information back to the Project. Not surprisingly, the stay at home orders, combined with our company ban on travel during Q3 made in-person meetings non-existent. However, the team was able to continue meeting with our partners and commercial users virtually. These meetings help us understand some of the applications where FreeBSD is used. We are currently scheduling Zoom company meetings for Q4, please reach out if you would like to schedule a meeting with us. Fundraising Efforts Last quarter we raised $192,874.43! Thank you to the individuals and organizations that stepped in, to help fund our efforts. We'd like to thank Arm for their large contribution last quarter, which helped bring our 2020 fundraising effort to $521k. We hope other organizations will follow their lead and give back to help us continue supporting FreeBSD. These are trying times, and we deeply appreciate every donation that has come in from $5 to $150,000. We're still here giving 110% to supporting FreeBSD! We are 100% funded by donations, and those funds go towards software development work to improve FreeBSD, FreeBSD advocacy around the world, keeping FreeBSD secure, continuous integration improvements, sponsoring BSD-related and computing conferences (even the virtual events!), legal support for the Project, and many other areas. Please consider making a donation to help us continue and increase our support for FreeBSD. We also have the Partnership Program, to provide more benefits for our larger commercial donors. Find out more information about the partnership program and share with your companies! OS Improvements A number of FreeBSD Foundation grant recipients started, continued working on, or completed projects during the third quarter. These include: * Ongoing WiFi and Linux KPI layer improvements. * Linuxulator application compatibility. * DRM / Graphics driver updates. * Zstd compression for OpenZFS. * Online RAID-Z expansion. * Modernized LLDB target support for FreeBSD. You can find more details about most of these projects in other quarterly reports. Staff members also worked on a number of larger projects, including: * Run-Time Dynamic Linker (rtld) and kernel ELF loader improvements. * Rewritten UNIX domain socket locking. * Build infrastructure. * Open system call path handling support for O_BENEATH, O_RESOLVE_BENEATH. * arm64 support. * Migration to a Git repository. Many of these projects also have detailed entries in other quarterly report entries. Staff members also put in significant effort in many ways other than larger, individual projects. These include assisting with code reviews, bug report triage, security report triage and advisory handling, addressing syzkaller reports, and ongoing maintenance and bug fixes in functional areas such as the tool chain, developer tools, virtual memory kernel subsystem, low-level x86 infrastructure, sockets and protocols, and others. University of Waterloo Co-op With the transition to working from home, the Foundation decided to again take on three University of Waterloo Co-op students for the Fall 2020 term (September to December). Tiger returns for a second term, joined by new students Yang and Zac. Projects for the term include more work on ELF Tool Chain, application of Capsicum to additional utilities, testing and integration of FreePBX and Asterisk VOIP software, pkgbase, and exploring containerization tooling. Continuous Integration and Quality Assurance The Foundation provides a full-time staff member and funds projects on improving continuous integration, automated testing, and overall quality assurance efforts for the FreeBSD project. During the third quarter of 2020, Foundation staff continued improving and monitoring the Project's CI infrastructure, and working with experts to fix the failing builds and the regressions found by tests. The setting up of dedicated VM host for running tests is completed. New feature developments and the CI staging environment is in progress. We are also working with other teams in the Project for their testing needs. For example, tests of non-x86 architectures now run periodically, and improve the CI of the embedded systems. We are also working with many external projects and companies to improve the CI between their products and FreeBSD. See the FreeBSD CI section of this report for completed work items and detailed information. Supporting FreeBSD Infrastructure The Foundation provides hardware and support to improve the FreeBSD infrastructure. Last quarter, we continued supporting FreeBSD hardware located around the world. We coordinated efforts between the new NYI Chicago facility and clusteradm to start working on getting the facility prepared for some of the new FreeBSD hardware we are planning on purchasing. NYI generously provides this for free to the Project. We also worked on connecting with the new owners of the Bridgewater site, where most of the FreeBSD infrastructure is located. Some of the purchases we made for the Project last quarter to support infrastructure includes: * Spamhaus spam filtering software to limit the amount of spam on the mailing lists. * 5 application servers to run tasks like bugzilla, wiki, website, cgi, Phabricator, host git, etc. * 1 server to replace the old pkg server and provide a lot more IOPS to avoid the slowdowns seen during peak times of the day where the disks just cannot keep up with the request volume. * 1 server for exp-runs to make them faster. * 1 server to build packages more frequently. FreeBSD Advocacy and Education A large part of our efforts are dedicated to advocating for the Project. This includes promoting work being done by others with FreeBSD; producing advocacy literature to teach people about FreeBSD and help make the path to starting using FreeBSD or contributing to the Project easier; and attending and getting other FreeBSD contributors to volunteer to run FreeBSD events, staff FreeBSD tables, and give FreeBSD presentations. 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, to work together on projects, and to facilitate 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. As is the case for most of us in this industry, COVID-19 has put our in-person events on hold. In addition to attending 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: * Launched our FreeBSD Fridays series of 101 classes. Topics included an Introduction to FreeBSD, FreeBSD Installfest, Introduction to Security, Introduction to ZFS and more. Videos of the past sessions and a schedule of upcoming events can be found here. * Attended and presented at OSI's State of the Source conference. The event was held virtually, September 9-11, 2020. * Launched the redesign of the FreeBSD Foundation Website. * Announced the 20th Anniversary of the FreeBSD Foundation. * Participated as an Admin for Google Summer of Code 2020 * Continued to promote the FreeBSD Office Hours series including holding our own Foundation led office hours. Videos from the one hour sessions can be found on the Project's YouTube Channel. You can watch ours here. * Interviewed members of the outgoing FreeBSD Core Team to get their thoughts on their term. * Began working with the FreeBSD Vendor Summit planning committee on the November 2020 Vendor Summit. * Promoted the Foundation's 20th Anniversary and our work to support the FreeBSD Project in the It's FOSS Article. FreeBSD Foundation Celebrates 20 Years of Promoting and Supporting FreeBSD Project. * Authored a Beginners Guide to FreeBSD for Fosslife. * Committed to sponsoring All Things Open as a media Sponsor. * Committed to sponsoring the OpenZFS Developers Summit at the Bronze level. * Became an International RISC-V Member. * Committed to giving a FreeBSD talk at the nerdear.la conference on October 20th. Keep up to date with our latest work in our monthly newsletters. Netflix provided an update on how and why they use FreeBSD in our latest Contributor Case Study. 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. We updated our Trademark Usage Terms and Conditions on July 1, 2020. Go to the FreeBSD Foundation's web site to find out how we support FreeBSD and how we can help you! ### Other We welcomed Andrew Wafaa and Kevin Bowling to our board of directors, to help govern the Foundation and guide us with our strategic direction. We have more information about our new board members on our website. __________________________________________________________________ FreeBSD Release Engineering Team Links FreeBSD 12.2-RELEASE schedule=20 URL: https://www.freebsd.org/releases/12.2R/schedule.html FreeBSD 12.2 test builds=20 URL: https://www.freebsd.org/where.html#helptest FreeBSD development snapshots=20 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 third quarter of 2020, the Release Engineering Team started work on the 12.2-RELEASE cycle, the third release from the stable/12 branch. As of this writing, two BETA builds have been released, with the expectation there will be a third BETA build currently remaining on the schedule. The 12.2-RELEASE cycle will continue throughout October, with two RC builds currently planned, and RC3 scheduled on an as-needed basis. The 12.2-RELEASE is so far scheduled for final release on October 27. In addition to the 12.2-RELEASE, Glen Barber of the Release Engineering Team finished work to the release build tools and scripts to prepare for the conversion from Subversion to Git for the 13.0-RELEASE cycle. There are no plans to merge these changes to stable branches at this time; as discussed within the Git working group, we feel such a change on a stable branch would be too intrusive to our user base as well as downstream FreeBSD consumers. Development snapshot builds for 13.0-CURRENT have recently been built from the Git tree within the project, and further snapshot builds for 12.x and 11.x will continue to be built from Subversion. Additionally throughout the quarter, several development snapshots builds were released for the head, stable/12, and stable/11 branches. Finally, the Release Engineering Team would like to thank Marius Strobl for his time serving on the team; he had recently stepped down from the Deputy RE Lead role due to constraints on his time. The Team welcomes Colin Percival, who has accepted fulfilling this role. Much of this work was sponsored by Rubicon Communications, LLC (netgate.com) and the FreeBSD Foundation. __________________________________________________________________ Cluster Administration Team Links Cluster Administration Team members=20 URL: https://www.freebsd.org/administration.html#t-clusteradm Contact: Cluster Administration Team The FreeBSD Cluster Administration Team consists of the people responsible for administering the machines that the Project relies on for its distributed work and communications to be synchronised. In this quarter, the team has worked on the following: * Work with the FreeBSD Foundation on hardware update for web services, mirror and package building servers. * Disable directory indexing on the package mirrors to resolve performance issues of the machine. + This was later relaxed to allow indexing of the parent directories but still disallow the large package directories. * Ongoing systems administration work: + Accounts management for committers. + Backups of critical infrastructure. + Keeping up with security updates in 3rd party software. Work in progress: * Setup Malaysia (KUL) mirror. * Setup Brazil (BRA) mirror. * Review the service jails and service administrators operation. * Infrastructure of building aarch64 and powerpc64 packages. + NVMe issues on PowerPC64 POWER9 blocking dual socket machine from being used as pkg builder. + Drive upgrade test for pkg builders (SSDs) courtesy of the FreeBSD Foundation. + Boot issues with Aarch64 reference machines. * New NYI.net sponsored colocation space in Chicago-land area. * Work with git working group for the git repository. * Searching for more providers that can fit the requirements for a generic mirrored layout or a tiny mirror. __________________________________________________________________ Continuous Integration Links FreeBSD Jenkins Instance=20 URL: https://ci.FreeBSD.org FreeBSD Hardware Testing Lab=20 URL: https://ci.FreeBSD.org/hwlab FreeBSD CI artifact archive=20 URL: https://artifact.ci.FreeBSD.org FreeBSD CI weekly report=20 URL: https://hackmd.io/@FreeBSD-CI FreeBSD Jenkins wiki=20 URL: https://wiki.freebsd.org/Jenkins Hosted CI wiki=20 URL: https://wiki.freebsd.org/HostedCI 3rd Party Software CI=20 URL: https://wiki.freebsd.org/3rdPartySoftwareCI Tickets related to freebsd-testing@=20 URL: https://preview.tinyurl.com/y9maauwg FreeBSD CI Repository=20 URL: https://github.com/freebsd/freebsd-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 firstly 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 codes or adjust test infrastructure. The details of these efforts are available in the weekly CI reports. During the third quarter of 2020, 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 changes: * All !x86 -test builds now trigger a new build on 22:00 UTC daily; this was not running very often because running all the tests in qemu takes lots of time. The work on improving the test execution speed and parallelism is in progress. The following is a list of the jobs affected: + Test build for FreeBSD HEAD on ARMv7. + Test build for FreeBSD HEAD on AArch64. + Test build for FreeBSD HEAD on MIPS64. + Test build for FreeBSD HEAD on PowerPC64. + Test build for FreeBSD HEAD on RISC-V64. * The build and test results will be sent to the dev-ci mailing list soon. Feedback and help with analysis is very appreciated! + A builder dedicated to run jobs using provisioned VMs is setup, this improves the stableness and reduces the execution time. + The result of FreeBSD-head-amd64-test_zfs is changed after OpenZFS importing; we encourage everyone to check and fix the failing and skipped test cases. New jobs added: * CI build for FreeBSD HEAD on PowerPC64LE. Work in progress: * Collecting and sorting CI tasks and ideas here. * Testing and merging pull requests in the the FreeBSD-ci repo. * Designing and implementing pre-commit CI building and testing, * Reduce 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 automatic tests on bare metal hardware. * Adding drm ports building tests against -CURRENT. * Planning to run ztest and network stack tests. * Adding more external toolchain related jobs. * Improving the hardware lab to be more mature and adding more hardware. * Helping more 3rd software get CI on FreeBSD through a hosted CI solution. * 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=20 URL: https://www.FreeBSD.org/ports/ Contributing to Ports=20 URL: https://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributing/= ports -contributing.html FreeBSD Ports Monitoring=20 URL: http://portsmon.freebsd.org/index.html Ports Management Team=20 URL: https://www.freebsd.org/portmgr/index.html Contact: Ren=C3=A9 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. We passed the landmark of 40,000 ports in the Ports Collection and are now around 40,400 ports. The last quarter saw 9335 commits to the HEAD branch and 481 commits to the 2020Q3 branch by respectively 167 and 63 committers. There are currently 2525 open problem reports of which 595 are unassigned. Compared to last quarter, this means a slight decrease in activity and also a slight increase in open PRs. During the last quarter we welcomed Rainer Hurling (rhurlin@) and said goodbye to Kevin Lo (kevlo@) and Grzegorz Blach (gblach@). The last three months saw new default versions for Perl (5.32), PostgreSQL (12) and PHP (7.4). Various packages also got updated: Firefox to 81.0.1, Chromium to 84.0.4147.135, Gnome to 3.36, Xorg to 1.20.9, Qt5 to 5.15.0, Emacs to 27.1, KDE Frameworks to 5.74.0 and pkg itself to 1.15.8. Never tired, antoine@ ran 30 exp-runs to test port version updates, on such diverse matters as: * Updating byacc in base to 20200330. * Check balancing of sed "y" command. * Use of brackets. * Removing the now redundant "port" argument from USES=3Dreadline. __________________________________________________________________ FreeBSD Office team - 3rd quarter 2020 report Links The FreeBSD Office project=20 URL: https://wiki.freebsd.org/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 focused on providing the latest stable release of LibreOffice suite and companion apps to all FreeBSD users. * Alongside with updating old stable branch to latest 6.4.x releases, current ports-tree now have a full-featured cutting-edge 7.0.1 bundle. * Conservative users can keep 6.4.x stable version by switching to use all-in-one editors/libreoffice6 port and even with i18n language pack (off by default). It will be kept updated at least till 7.1.0 version is released. We are looking for people to help the project. All unstable work with LibreOffice snapshots is staged in our WIP repository. The open bugs list contains all filed issues which need some attention. Patches, comments and objections are always welcome in the mailing list and bugzilla. __________________________________________________________________ FreeBSD Graphics Team status report Links Project GitHub page=20 URL: https://github.com/FreeBSDDesktop Contact: FreeBSD Graphics Team Contact: Niclas Zeising The FreeBSD X11/Graphics team maintains the lower levels of the FreeBSD graphics stack. This includes graphics drivers, graphics libraries such as the MESA OpenGL implementation, the X.org xserver with related libraries and applications, and Wayland with related libraries and applications. There have been several updates to the FreeBSD graphics stack and related libraries since the last report. Most notably, MESA related ports were changed to use the meson build system, instead of the autotools based one. This was needed since mesa upstream has deprecated and removed the autotools build system, and this paved the way for further mesa updates. While there was a need for a few minor corrections after the initial update, this update has been successful and made it possible to further update and improve the FreeBSD mesa port. There have also been several security fixes for xorg-server and libX11, so these ports have been updated to fix these issues. During the period, FreeBSD 12 was changed to improve the compatibility with input devices using udev/evdev and libinput. This change removes the need for local configuration and makes most mice, touchpads and keyboards work out of the box. This change will be in the upcoming FreeBSD 12.2 release. There have also been several updates to various libraries, both in the graphics and input stacks, and several userland drivers have been updated. Libraries such as libdrm and libevdev have been updated to include new FreeBSD support, developed by team members and added upstream. There has also been ongoing work to keep the various drm-kmod ports and packages up to date, mostly in response to changes in various FreeBSD versions. We have also continued our regularly scheduled bi-weekly meetings. People who are interested in helping out can find us on the x11@FreeBSD.org mailing list, or on our gitter chat. We are also available in #freebsd-xorg on EFNet. We also have a team area on GitHub where our work repositories can be found. __________________________________________________________________ Projects Projects that span multiple categories, from the kernel and userspace to the Ports Collection or external projects. FreeBSD on Microsoft HyperV and Azure Links Microsoft Azure article on FreeBSD wiki =20 URL: https://wiki.freebsd.org/MicrosoftAzure Microsoft HyperV article on FreeBSD wiki=20 URL: https://wiki.freebsd.org/HyperV Contact: FreeBSD Integration Services Team Contact: Wei Hu Contact: Li-Wen Hsu Li-Wen is working on the FreeBSD release code related to Azure for the -CURRENT, 12-STABLE and 11-STABLE branches. The work-in-progress is available here. The 11.4-RELEASE image on Azure Marketplace is published. We are testing the releng/12.2 branch and 12.2-RELEASE image will be published to Azure Marketplace soon after released. This project is sponsored by The FreeBSD Foundation, with resources provided by Microsoft. __________________________________________________________________ Building FreeBSD on non-FreeBSD hosts Links Wiki=20 URL: https://wiki.freebsd.org/BuildingOnNonFreeBSD Contact: Alex Richardson Until recently FreeBSD could only be built on a FreeBSD host. However, many popular free CI tools only allow building on Linux or macOS and therefore can not be used for building the FreeBSD base system. Furthermore, it is sometimes useful to cross-build FreeBSD for a remote machine or an emulator even if the build machine is not running FreeBSD. The goal of this project is to allow building the base system on Linux and macOS hosts. I started this project in 2017 to allow building CheriBSD on the Linux servers and desktops that many of us working on the CHERI project use. The first few patches were upstreamed in 2018 (see the 2018q3 report) and I merged the full set of patches to CheriBSD shortly after. Over the past two years I have slowly been upstreaming the remaining patches and finally committed the last required change in time for this report. As of September 2020 it should be possible to use the buildworld and buildkernel make targets to build a fully-functional FreeBSD installation on macOS and Linux hosts. We use this in our continuous integration system to build and test CheriBSD disk images for multiple architectures. I have also committed a GitHub Actions configuration upstream that takes approximately 10 minutes to build an amd64 kernel. This will ensure that changes that break crossbuilding from Linux/macOS can be detected easily. Upstreaming the crossbuilding changes has resulted in various build system cleanups. For example, we now no longer need to use lorder.sh when building libraries which speeds up the linking step a bit. The portability and bootstrapping changes should also make it easier to upgrade from older versions since we no longer rely on host headers in /usr/include matching those of the target system (e.g. when bootstrapping localedef, etc.). While this support for building on Linux and macOS should still be considered experimental, it should work in many cases. If you would like to give it a try, the following command line should successfully build an amd64 world on Linux and macOS systems that have packages for LLVM 10 (or newer) installed: MAKEOBJDIRPREFIX=3D/somewhere ./tools/build/make.py TARGET=3Damd64 TARGET_ARCH=3Damd64 buildworld Buil= ds must be performed using the ./tools/build/make.py wrapper script since most Linux and macOS systems do not ship an appropriate version of bmake. Please let me know if you encounter any issues. Sponsor: DARPA __________________________________________________________________ Git Migration Working Group Links Git conversion tooling repo=20 URL: https://github.com/freebsd/git_conv FreeBSD-git mailing list=20 URL: https://lists.freebsd.org/mailman/listinfo/freebsd-git Beta doc git repo=20 URL: https://cgit-beta.FreeBSD.org/doc Beta ports git repo=20 URL: https://cgit-beta.FreeBSD.org/ports Beta src git repo=20 URL: https://cgit-beta.FreeBSD.org/src Contact: Ed Maste Contact: Warner Losh Contact: Ulrich Sp=C3=B6rlein Work continues on FreeBSD's migration from Subversion to Git. Ulrich has addressed all known issues with svn2git and has been able to work around the inconsistent metadata and forced commit issues in the Subversion history. We still have additional documentation to write, and need to finish installing commit hooks (e.g. restricting branch creation, or ensuring appropriate data exists on cherry-pick commits). We expect to open the beta repository to test commits before the end of October. This is to allow testing of the commit hooks, and to allow developers to test access and become familiar with git operation. Commits in this repository will be deleted and the repository will be recreated at least once prior to the final migration. Those with an interest in the migration to Git are encouraged to subscribe to the FreeBSD-git mailing list and test out the beta src, ports, and/or doc repositories. You are also welcome check out the wiki, issues, README and other documentation at the Git conversion tooling repo. We currently expect to transition the src and doc repositories in mid-November. Additional investigation and experimentation with the ports repository is still underway. Sponsor: The FreeBSD Foundation (in part) __________________________________________________________________ Linux compatibility layer update Contact: Edward Tomasz Napierala Contact: Mark Johnston Earlier Linuxulator work focused on code cleanups and improving diagnostic tools. Work has now shifted from cleanups to fixing actual applications. Current status is being tracked at Linux app status Wiki page. Initial focus was on applications that don't involve X11, mostly because they tend to be easier to test and debug, and the bug fixes are not application-specific. Foundation-sponsored work during this quarter included implementing a devfs(5) workaround to fix gettynam(3) inside jail/chroot, and workaround for the missing splice(2) syscall, which caused problems for grep and autotools. The Linux version reported to userspace was bumped to 3.10.0, which matches the kernel shipped with RHEL 7 and is neccessary for IBM's DB2 database installation to succeed. The BLKPBSZGET ioctl neccessary for Oracle database is supported now. There is now support for kcov(4), neccessary for syzcaller; as well as a number of fixes for issues reported by syzcaller, such as futex lock leaks. There were also more cleanups, including moving some Linuxulator-specific functionality related to error handling off from the syscall's fast code paths. The sysutils/debootstrap port, which provides an easy way to create Debian or Ubuntu jail, was updated to version 1.0.123. Finally there were some improvements to the documentation. Most of those changes have been merged to FreeBSD 12-STABLE, in order to ship with 12.2-RELEASE. There is increased involvement from other developers; this includes termios performance fixes, improved memfd support, implementing CLOCK_MONOTONIC_RAW required for Steam, madvise improvements, new compat.linux.use_emul_path sysctl. There is also ongoing work on tracking down the causes of failures related to Steam and WebKit, with fixes being first implemented in linuxulator-steam-utils. Sponsor: The FreeBSD Foundation __________________________________________________________________ LLDB Debugger Improvements Links Moritz Systems Project Description=20 URL: https://www.moritz.systems/blog/lldb-debugger-improvements-for-fre= ebsd/ Git Repository=20 URL: https://github.com/moritz-systems/llvm-project Contact: Kamil Rytarowski Contact: Michal G=C3=B3rny FreeBSD includes LLDB, the debugger in the LLVM family, in the base system. At present it has some limitations in comparison with the GNU GDB debugger, and does not yet provide a complete replacement. It relies on an obsolete plugin model in LLDB that causes growing technical debt. This project aims to bring LLDB closer to a fully featured replacement for GDB, and therefore for FreeBSD to feature a modern debugger for software developers. The legacy monolithic target supports the executed application being debugged in the same process space as the debugger. The modern LLDB plugin approach, used on other supported targets, executes the target process under a separate lldb-server process. This improves reliability and simplifies the process / thread model in LLDB itself. In addition, remote and local debugging will both be performed using the same approach. After the migration to the new process model is complete, the project will include reviewing the results of LLDB's test suite and fixing tests as time permits. The work is expected to be complete in 2020. The project schedule is divided into three milestones, each taking approximately one month: 1. Introduce new FreeBSD Remote Process Plugin for x86_64 with basic support and upstream to LLVM. 2. Ensure and add the mandated features in the project (process launch, process attach (pid), process attach (name), userland core files, breakpoints, watchpoints, threads, remote debugging) for FreeBSD/amd64 and FreeBSD/i386. 3. Iterate over the LLDB tests. Detect, and as time permits, fix bugs. Ensure bug reports for each non-fixed and known problem. Add missing man pages and update the FreeBSD Handbook. We are nearing the completion of the first milestone. The new plugin is getting into shape, and it can already run simple single-threaded programs. The supported features include single-stepping, breakpoints, memory and register I/O on amd64. Both plugins are supported simultaneously. The new plugin is used if FREEBSD_REMOTE_PLUGIN environment variable is set to any value, or if lldb-server is spawned directly. Otherwise, the old plugin is used for compatibility. Once the new plugin matures, we are planning to enable it unconditionally on the architectures that it is ported to. Sponsor: The FreeBSD Foundation __________________________________________________________________ Lua usage in FreeBSD Contact: Ed Maste Contact: Kyle Evans Contact: Ryan Moeller During this quarter, flua (FreeBSD Lua) was taught where to find base .lua modules in order to support require of .lua modules to be provided by the base system. flua also gained support for require of binary modules. A review for libjail bindings has also been submitted, pending review. libjail is an essential component if one wants to be able to write jail management utilities in flua. People interested in working with Lua in FreeBSD are welcome to get in contact to discuss other project ideas. To name a couple of potential projects, some interesting modules that have not been started but could prove useful (listed in no particular order): * libcrypt * libexpat * libnv * libxo There is also a small list of scripts that would do well with a port to flua: * certctl(8) __________________________________________________________________ NFS over TLS implementation Contact: Rick Macklem In an effort to improve NFS security, an internet draft which I expect will become an RFC soon specifies the use of TLS 1.3 to encrypt all data traffic on a Sun RPC connection used for NFS. Although NFS has been able to use sec=3Dkrb5p to encrypt data on the wire, this requires a Kerberos environment and, as such, has not been widely adopted. It also required that encryption/decryption be done in software, since only the RPC message NFS arguments are encrypted. Since Kernel TLS is capable of using hardware assist to improve performance and does not require Kerberos, NFS over TLS may be more widely adopted, once implementations are available. The coding for this project has now been completed. All required changes to the NFS and kernel RPC code have been committed to -CURRENT. The daemons are now believed to be complete, but will remain in base/projects/nfs-over-tls until -CURRENT has an OpenSSL library with the kernel TLS support incorporated in it. If this does not happen for FreeBSD-13, hopefully the patched OpenSSL and the daemons can become ports. To support clients such as laptops, the daemons that perform the TLS handshake may optionally handle client X.509 certificates from a site local CA. There are now exports(5) options to require client(s) to provide a valid X.509 certificate. While setting up system(s) for testing is still a little awkward, the documentation is now available for those who want to help with testing. The main limitation in the current implementation is that it uses TLS1.2 and not TLS1.3. This should change once the KERN_TLS rx patch includes TLS1.3 support. Third party testing would be appreciated. __________________________________________________________________ syzkaller on FreeBSD Contact: Mark Johnston See the syzkaller entry in the 2019q1 quarterly report for an introduction to syzkaller. syzkaller, especially the public syzbot instance, continues to find bugs in the FreeBSD kernel. A number of these bugs have been fixed in subsystems such as the VFS name cache, the TCP and SCTP stacks, pf(4), the unix domain socket implementation, and the Linuxulator. The FreeBSD Foundation sponsored some work to enable cross-OS fuzzing. This makes it possible to fuzz the Linuxulator using syzkaller's Linux target. This effort quickly found several bugs; once the support is committed upstream we will hopefully be able to leverage syzbot to gain continuous testing of the Linux system call interface in addition to the native and 32-bit compatibility interfaces. Some work was also done to enable running syzkaller in a FreeBSD jail, with the eventual aim of making it easy to distribute binary images containing everything required to immediately start running syzkaller on a new host. Currently a number of setup steps are required, making deployment somewhat painful. Sponsor: The FreeBSD Foundation __________________________________________________________________ Kernel Updates to kernel subsystems/features, driver support, filesystems, and more. DRM Drivers Update Links drm-kmod=20 URL: https://github.com/freebsd/drm-kmod/ Contact: Emmanuel Vadot The drm drivers for FreeBSD 13-CURRENT have been updated to match Linux 5.4.62 Then graphics/drm-current-kmod have been updated to follow this LTS release of Linux. For now graphics/drm-devel-kmod is also tracking this release but will be updated to a later revision of Linux drm drivers in the near future. A lot of linuxkpi code was removed from the ports or replaced with a BSD licenced implementation. Sponsor: The FreeBSD Foundation __________________________________________________________________ DTS Update Contact: Emmanuel Vadot DTS files (Device Tree Sources) were updated to be on par with Linux 5.8 for HEAD and 5.6 for the 12-STABLE branch. __________________________________________________________________ DesignWare Ethernet adapter driver improvements Links WIP branch=20 URL: https://github.com/gonzoua/freebsd/tree/rk_eth Contact: Oleksandr Tymoshenko DesignWare Ethernet adapter IP is used in Rockchip and Allwinner SoCs. The driver was updated with following fixes: * Initialize clocks instead of relying on u-boot to do the right thing. * Sense media type and adjust controller configuration accordingly. * Add support for RMII PHY mode. Yet uncommitted changes include performance optimisation by adding support for multi-segment mbuf transmission. The next step is to try to get more performance boost by using interrupt coalescence. __________________________________________________________________ Google Summer of Code'20 Project - eBPF XDP Hooks Links Github diff link=20 URL: https://github.com/Ankurk99/freebsd/tree/ebpf-import Project wiki =20 URL: https://wiki.freebsd.org/SummerOfCode2020Projects/eBPFXDPHooksl Contact: Ankur Kothiwal The eBPF eXpress Data Path (XDP) allows eBPF programs to be run to filter received packets as early as possible, avoiding unnecessary processing overhead before the filter is run. The goal of this project is to extend an existing FreeBSD network driver (a virtual NIC like a VirtIO if_vtnet) to be able to call into an eBPF program when processing a newly received packet. In short, with XDP the driver must PASS (accept and process normally), DROP, TX or REDIRECT the packet as specified by the program. eBPF helper functions and maps for aiding in packet filtering will also be implemented. Implemented: * Register a eBPF probe when an interface is registered with pfil. * Activating eBPF probe. * Create hooks and link them to the pfil head when the eBPF XDP probe is activated and successfully list the XDP probes. * Create a xdp_rx function which will pass the received packets to the eBPF program where the packets can be further processed. This function will return XDP actions: DROP and PASS. * Register the xdp hook and link it to the pfil head. * Write an eBPF program to process (currently drop and pass) ICMP traffic - This is to test that the hook is working properly. * Write a loader function to load the ICMP filter program to the kernel. Future Work: * Currently we can only attach the XDP hook to PASS and DROP the packets - The work on detaching the hook is left. * The XDP action to "TX" and "REDIRECT" the packets. Final Deliverables: * Implemented XDP hook to pass and drop packets. * Created a loader program to attach the eBPF program to the kernel. * A test program to DROP ICMP filter. This code was done under the Google Summer of Code 2020 under the guidance of Ryan Stone (rstone@). The eBPF implementation for FreeBSD is still a work in progress and FreeBSD doesn't support eBPF yet. The basic implementation for eBPF was a GSoC'18 project, and is still under development. This project is based on that implementation so the XDP implementation for FreeBSD can only be merged into the FreeBSD source code once it supports eBPF. Currently this code is a work in progress and is merged to Ryan Stone's branch with support for the eBPF implementation. Sponsor: Google Summer of Code __________________________________________________________________ ENA FreeBSD Driver Update Links ENA README=20 URL: https://github.com/amzn/amzn-drivers/blob/master/kernel/fbsd/ena/R= EADME Contact: Michal Krawczyk Contact: Artur Rojek 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: * Fix ENA compilation in case it is integrated into the kernel binary. * MFC of the ENA v2.2.0 driver to the FreeBSD 12.2. Work in progress: * Add feature that allows reading extra ENI (Elastic Network Interface) metrics about exceeding BW/pps limits. * Introduce full kernel RSS API support. * Allow reconfiguration of the RSS indirection table and hash key. * Evaluation and prototyping of the driver port to the iflib framework. Sponsor: Amazon.com Inc __________________________________________________________________ IPSec Extended Sequence Number (ESN) support Contact: Grzegorz Jaszczyk Contact: Patryk Duda Contact: Marcin Wojtas Extended Sequence Number (ESN) is IPSec extension defined in RFC4303 Section 2.2.1. It makes possible to implement high-speed IPSec implementations where standard, 32-bit sequence number is not sufficient. A key feature of the ESN is that only low order 32 bits of sequence number are transmitted over the wire. High-order 32 bits are maintained by sender and receiver. Additionally high-order bits are included in the computation of Integrity Check Value (ICV) field. Extended Sequence Number support contains following: * Modification of existing anti-replay algorithm to fulfil ESN requirements. * Trigger soft lifetime expiration at 80% of UINT32_MAX when ESN is disabled. * Implement support for including ESN into ICV in cryptosoft engine in both encrypt and authenticate mode (eg. AES-CBC and SHA256 HMAC) and combined mode (eg. AES-GCM). * Implement support for including ESN into ICV in AES-NI engine in both encrypt and authenticate mode and combined mode. Completed since the last update: * Adjust implementation of crypto part to the reworked Open Crypto Framework. * Move the core ESN implementation from the crypto drivers to netipsec layer. * Make use of the newly introduced crp_aad mechanism for combined modes. * Introduce minor fixes and improvements. TODO: * Complete review process in Phabricator and merge patches in the tree. Sponsor: Stormshield __________________________________________________________________ NXP ARM64 SoC support Contact: Marcin Wojtas Contact: Artur Rojek Contact: Dawid Gorecki The Semihalf team initiated working on FreeBSD support for the NXP LS1046A SoC LS1046A are quad-core 64-bit ARMv8 Cortex-A72 processors with integrated packet processing acceleration and high speed peripherals including 10 Gb Ethernet, PCIe 3.0, SATA 3.0 and USB 3.0 for a wide range of networking, storage, security and industrial applications. Completed since the last update: * Upstreaming of the QorIQ SDHCI driver (r365054). With above the current Semihalf upstreaming activity is complete. The major out-of-tree supported components: * DPAA network controller support. * QSPI controller support. They work on 11.2-RELEASE, but still require significant effort to adopt to FreeBSD-CURRENT. Sponsor: Alstom Group __________________________________________________________________ Addition of PowerPC64LE Architecture Links Early notes=20 URL: https://lists.freebsd.org/pipermail/freebsd-ppc/2020-August/012043= =2Ehtml Announcement=20 URL: https://lists.freebsd.org/pipermail/freebsd-ppc/2020-September/012= 098.h tml Contact: Brandon Bergren As of r366063, experimental support for little-endian PowerPC64 (PowerPC64LE) is available in -CURRENT for POWER8 and POWER9 machines. In 2010, when FreeBSD was ported to PowerPC64, the average user would have been using a G5 PowerMac, a purely big-endian machine. While, at the time, a 32-bit PowerPC machine could run in little-endian, as well as POWER6 and POWER7, in practice, the complexities involved in managing it at the kernel level and lack of firmware support made it infeasible to support. When IBM designed POWER8, one main focus was to improve little-endian support, and bring it up to parity with big-endian. This improved support makes it practical to support a little-endian operating environment on what is traditionally a primarily big-endian platform. In 2020, with POWER9 being affordable for many users thanks to the Raptor Blackbird, semi-easy access to surplus POWER8 hardware, IBM having a major future focus on POWER little-endian, and the decay of big-endian support in modern video cards and graphical environments, there is demand for a little-endian version of FreeBSD on POWER. With FreeBSD/PowerPC64's transition in 2019 to the ELFv2 ABI as part of the 2019q4 PowerPC on Clang effort, the last major barrier to a little-endian port was eliminated. Since nobody else was working on it, and I had the skillset required to do the port, I decided to experiment one weekend with a little-endian kernel to see how difficult it would be to port. It turned out to be a lot more trivial than I was expecting. Three days later I had console support in qemu, and after another week of debugging, I had it fully up and running on hardware. FreeBSD PowerPC64LE is now an experimental MACHINE_ARCH in base, and is continuing to evolve at a rapid pace. Big-endian PowerPC64 is still the preferred platform for the foreseeable future, and will not be deprecated. Sponsor: Tag1 Consulting, Inc. __________________________________________________________________ ure - USB 3.0 Gigabit Ethernet Driver update Links svn commit: r365648=20 URL: https://svnweb.freebsd.org/changeset/base/365648 FreeBSD-SA-20:27.ure=20 URL: https://www.freebsd.org/security/advisories/FreeBSD-SA-20:27.ure.a= sc D25809 major update to if_ure=20 URL: https://reviews.freebsd.org/D25809 Contact: John-Mark Gurney The ure is a driver for handling the RealTek ethernet adapters, including the RTL8153 USB 3.0 Gigabit ethernet adapters. It is used in many ethernet dongles and docking stations. Previous to this update, the driver was limited in speed. In my testing, I was only able to get ~91Mbps. This limit was due to one packet per USB transfer. USB has a limit of 8000 transfers per second (1500 bytes/pkt * 8000 pkts/sec * 8bits/byte =3D=3D 96 Mbps). This was acceptable for fast ethernet (RTL8152, 100Mbps), but with the additional support for Gigabit ethernet, it became a bottleneck. The updates add sending and receiving multiple packets in a single USB transfer, VLAN hardware tagging, and enable TCP and UDP checksum offloading. This increased the speed on gigabit ethernet to ~940 Mbps. In doing this work, a security vulnerability was discovered in the driver. Due to improper setting of a device register, on some devices, it caused packets to be fragmented when they shouldn't be and the driver was unable to handle them correctly. This allowed an attacker, who could generate large frames (say, ping packets, or large TCP transfers), to inject arbitrary packets into the network stack. This could allow the attacker to spoof traffic from other machines, and bypass VLAN protections. See the SA for more information. As part of this work, a script was created to run tests to validate that basic functionality of the driver (w/o options) work properly, and then iterate over each option to make sure that they function properly. This will be released at some point in the future. If you're interested in helping out, or testing it, let me know. __________________________________________________________________ Stateless hardware offloads for VXLANs Links r365867=20 URL: https://svnweb.freebsd.org/base?view=3Drevision&revision=3Dr365867 r365868=20 URL: https://svnweb.freebsd.org/base?view=3Drevision&revision=3Dr365868 r365869=20 URL: https://svnweb.freebsd.org/base?view=3Drevision&revision=3Dr365869 r365870=20 URL: https://svnweb.freebsd.org/base?view=3Drevision&revision=3Dr365870 r365871=20 URL: https://svnweb.freebsd.org/base?view=3Drevision&revision=3Dr365871 RFC6935=20 URL: https://tools.ietf.org/html/rfc6935 Contact: Navdeep Parhar VXLAN (Virtual eXtensible LAN) is a tunneling protocol in which Layer 2 traffic for a virtual LAN is encapsulated in UDP and transferred over Layer 3 networks between VTEPs (VXLAN Tunnel End Points). Traffic on the wire has two sets of networking headers: the headers for the encapsulation and the headers of the traffic being encapsulated. VXLANs are supported by if_vxlan(4) on FreeBSD. Modern NICs commonly support header checksum insertion and verification, TSO (TCP Segmentation Offload) on transmit, and RSS for load distribution on receive. But the default is to operate on the outermost headers. Some NICs can operate on the inner encapsulated frames as well. The commits listed above allow if_vxlan(4) to take advantage of such NICs. r365867 and r365868 add new mbuf checksum flags and ifnet capabilities. r365870 implements the kernel parts of the new capabilities and updates if_vxlan(4) to make use of them. r365871 implements driver support for the new capabilities in cxgbe(4). VXLAN and other tunneling protocols that use UDP explicitly allow zero checksum in the outer UDP header, even with IPv6. r365869 adds support for configuring one UDP/IPv6 port where zero checksums are allowed. This work was sponsored by Chelsio Communications and was implemented and tested using T6 (Terminator 6) NICs supported by cxgbe(4). It is available in 13.0-CURRENT (head) right now and will be available in 12-STABLE in the future. VXLANs can be created as usual and will automatically have checksum and TSO capabilities if the underlying physical interface supports VXLAN stateless offloads. Use ifconfig to list, disable, and enable checksum capabilities on the VXLAN interface. Use https://bugs.freebsd.org/bugzilla/ to report bugs. Future work: * Direct call into a vxlan input routine from the driver's receive routine. * LRO support in if_vxlan(4). * GENEVE support. Sponsor: Chelsio Communications __________________________________________________________________ Wireless updates Links The freebsd-wireless mailing list=20 URL: https://lists.freebsd.org/mailman/listinfo/freebsd-wireless athp github repository=20 URL: https://github.com/erikarn/athp Contact: Adrian Chadd Contact: Bjoern A. Zeeb The following works happened in FreeBSD HEAD (some already in Q2) and were merged for 12.2-BETA2 and include net80211 and driver updates for better 11n and upcoming 11ac support. In more detail, this includes an ath(4) update, some run(4) 11n support, 11n for otus(4), A-MPDU, A-MSDU, A-MPDU+A-MSDU and Fast frames options, scanning fixes, enhanced PRIV checks for jails, restored parent device name printing, improvements for upcoming VHT support, lots of under-the-hood infrastructure improvements, new device IDs, and debug tools updates. If you have a chance please test before the release. Atheros 11ac driver athp In the last three months the athp(4) port of the ath10k driver has progressed well. Adrian reports the following important changes: * Per-node transmit buffering was implemented, required for correct hostap and QCA6174 behaviour. * Issues with ignoring sending some management frames got fixed; null-data frames were being filtered out and this caused undesirable hostap behaviour. * Transmit path refactoring reduced code duplication. * A fix on firmware start / VAP running tracking no longer stops the first VAP from coming active after VAP creation / ifconfig up. * Correcting hostap mode PHY configuration now allows non-VHT stations to associate and correctly exchange data with a VHT AP. * Addition of a crypto key configuration cache in the driver ensures the ieee80211_key details are available after the key is deleted; net80211 would reuse or free the state before the driver task would finish the firmware command. Newer Intel Wireless device support Initial work was done to integrate net80211 support in the LinuxKPI compat layer to get the wireless parts going. In addition, upstreaming code changes and working through problems and review started on two sides. One was trying to get mostly compile time changes upstreamed to the iwlwifi driver. The other is sorting out conflicting LinuxKPI changes to not break the DRM graphics drivers. Bjoern hopes that with some of that sorted out, he can soon go back to focus on the wireless parts and produce a new snapshot. rtw88 and brcmfmac As the Intel driver port and LinuxKPI advance, both the rtw88, and to a lower degree the brcmfmac, ports benefit from that. Bjoern lately also got a brcmfmac PCIe card and started to port support for that. This for the moment remains a free-time project. Work by Bjoern was sponsored by: Rubicon Communications, LLC (d/b/a "Netgate") and The FreeBSD Foundation __________________________________________________________________ ZSTD Compression in ZFS Contact: Allan Jude Zstandard (ZSTD) is a modern high-performance compression algorithm designed to provide the compression ratios of gzip while offering much better performance. ZSTD has been adopted in FreeBSD for a number of other uses, including compressing kernel crash dumps, as a replacement for gzip or bzip for compressing log files, and for future versions of pkg(8). This effort to complete the integration of ZSTD into ZFS is funded by the FreeBSD Foundation. During the third quarter the integrating of ZSTD into OpenZFS was completed in the upstream OpenZFS repository, and the new OpenZFS 2.0 codebase was imported into 13-CURRENT. Completed milestones in this project: * Importing ZSTD 1.4.5 into OpenZFS, using the recent upstream zstd features that make it easier to embed zstd in other projects. * Changing the way compression levels are tracked and inherited. * Save and restore the compression level via an embedded block header. * Also store the version of zstd used in the embedded block header, for future-proofing. The checksum of a block may not match if zstd is upgraded, since it may compress the block more. * Add tests to ensure zstd compression and metadata survive ZFS replication. * Resolve possible negative interactions with L2ARC and ZFS Native Encryption. * Fix bug with L2ARC if the Compressed ARC feature is disabled. * Improve the ZFS feature activation code, so that zstd cannot create pools that will panic older versions of ZFS. With these changes, upgraded pools can compress data with zstd or zstd-fast, across a wide range of different compression levels. This will allow the storage administrator to select the performance-vs-compression tradeoff that best suits their needs. Tasks remaining to be completed: * Add a section to the FreeBSD Handbook ZFS chapter about zstd * Create more documentation around selecting a suitable compression level * Finish support for ZSTD in the FreeBSD boot loader (Warner Losh imp@freebsd.org) Sponsor: The FreeBSD Foundation __________________________________________________________________ Architectures Updating platform-specific features and bringing in support for new hardware platforms. CheriBSD 2020 Q3 Links Contact: Alex Richardson Contact: Andrew Turner Contact: Brooks Davis Contact: Edward Tomasz Napierala Contact: George Neville-Neil Contact: Jessica Clarke Contact: John Baldwin Contact: Robert Watson Contact: Ruslan Bukin CheriBSD extends FreeBSD to implement memory protection and software compartmentalization features supported by the CHERI instruction-set extensions. There are three architectural implementations of the CHERI protection model: CHERI-MIPS, CHERI-RISC-V, and Arm's forthcoming experimental Morello processor (due late 2021). CheriBSD is a research operating system with a stable baseline implementation into which various new research features have been, or are currently being, merged: * Arm Morello - We are preparing to open source our adaptation of CheriBSD to Arm's Morello architecture. The Morello branch is being updated to the most recent CheriBSD baseline, and patches are in review for upstreaming to our open-source repository. CheriBSD currently boots and runs statically linked CheriABI binaries on the Morello simulator, and dynamic linking support is in progress, with OS and toolchain bugs being worked on. We aim to make a first CheriBSD/Morello snapshot available alongside other open-source Morello software in mid-October 2020, however, our target for a more mature and usable implementation is December 2020. * Kernel spatial memory safety (pure-capability kernel) - The current CheriBSD kernel is a hybrid C program where only pointers to userspace are CHERI capabilities. This ensures that the kernel follows the intent of the application runtime and cannot be used to defeat bounds on application pointers. We have developed and will soon merge a pure-capability kernel where all pointers in the kernel are appropriately bounded capabilities. This vastly reduces the opportunity for buffer overflows. This spatial memory safety lays the groundwork for future work such as device driver compartmentalization and kernel temporal safety. * Userspace heap temporal memory safety (Cornucopia) - CHERI capabilities provide the necessary features to enable robust and efficient revocation of freed pointers. With Cornucopia we have implemented a light-weight revocation framework providing protection from use-after-reallocation bugs with an average cost below 2%. We aim to bring these overheads down further over the next year and merge this functionality into the mainline CheriBSD. * We have been working on updating the arm64 bhyve from Politehnica University of Bucharest to have it committed to FreeBSD. We have been upstreaming initial changes to help support this. * Baseline FreeBSD improvements - We are upstreaming (to FreeBSD) various bug fixes and tweaks for PCIe support, and support for the System MMU (SMMU) that will be present on the N1SDP and Morello SoCs. We have upstreamed support for cross-building FreeBSD from macOS and Linux (with some limitations; see separate entry on crossbuilding). We have also fixed implementation bugs in the RISC-V ABI. CHERI Documentation and Exercises * We have released [Capability Hardware Enhanced RISC Instructions: CHERI Instruction-Set Architecture (Version 8)](https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-951.pdf). Notable changes include promotion of CHERI-RISC-V to non-experimental and discussion of Arm's Morello prototype. * We have developed a set of [Adversarial CHERI Exercises and Missions](https://ctsrd-cheri.github.io/cheri-exercises) to introduce security researchers to CHERI protections. __________________________________________________________________ FreeBSD/RISC-V Project Links Wiki=20 URL: https://wiki.freebsd.org/riscv Contact: Mitchell Horne Contact: freebsd-riscv Mailing List Contact: IRC #freebsd-riscv on freenode The FreeBSD/RISC-V project is providing support for running FreeBSD on the RISC-V Instruction Set Architecture. This quarter saw several important bug fixes. A number of hangs in the system were identified and addressed, and a bug in QEMU's implementation of the Platform Level Interrupt Controller was fixed. This fix is included in the new devel/qemu50 and devel/qemu-devel ports. The end result of these fixes is that the test suite can now be reliably run to completion in QEMU. The entire run takes several hours, so CI has been configured to run the job once a day. There is active effort into reducing the time it takes to run the entire test suite. A new u-boot port was created: sysutils/u-boot-qemu-riscv64. This variant can be used as a secondary bootloader alongside OpenSBI to load and launch FreeBSD's loader(8) from an EFI System Partition. Next quarter will likely bring further fixes to address some of the failing test cases. __________________________________________________________________ Ports Changes affecting the Ports Collection, whether sweeping changes that touch most of the tree, or individual ports themselves. Update to grub-bhyve Links grub-bhyve Git Repository=20 URL: https://gitlab.com/ctuffli/grub Contact: Chuck Tuffli bhyve is the hypervisor included in FreeBSD and other operating systems used to run virtual machines. When not using a boot ROM (i.e. UEFI), the user must load the guest operating system for bhyve. For non-FreeBSD guests, the loader is a version of GNU GRUB (a.k.a the GNU GRand Unified Bootloader) modified to interface with bhyve. This work is an effort to both update the base GRUB code to the latest version as well as improve the usability on FreeBSD. The current grub-bhyve is based on an older version of GRUB (circa 2015) and thus is missing more recent additions such as XFS file system and syslinux support. With the update, installing CentOS, for example, now does not require the extra step of changing the default file system to something other than XFS. Internally, the code has been restructured to be its own "platform" which should make it easier to keep in sync with upstream development. The major improvement is the ability to automatically find and load the GRUB configuration file from the guest disk image. With this change, it is not necessary to create a device map file or specify which Linux kernel or initrd image to use. More importantly, if the guest image updates its GRUB configuration, for example after updating the kernel, no changes are needed when invoking grub-bhyve. Note, this feature requires a new "disk" option: # grub-bhyve --disk=3D/zroot/vms/u18-mini/disk0.img --vm=3Du18-mini The automatic configuration file detection works with both GRUB configuration files (e.g. CentOS, Ubuntu) as well as syslinux configuration (e.g. Alpine). For the adventurous, there is experimental support for Fedora's BootLoaderSpec (a.k.a. blscfg) on the blscfg branch of the grub-bhyve Git repository. The code has been tested on a few Linux variants, but it would benefit from wider testing (and bug reports!). The new version does not have a Port but is easily built on FreeBSD. After cloning / downloading the source, run: $ PYTHON=3Dpython3.7 ./bootstrap $ MAKE=3Dgmake ./configure --with-platform=3Dbhyve $ gmake The resulting binary, grub-bhyve, will be in the grub-core/ directory. If you have success or troubles with it, please let me know. __________________________________________________________________ KDE on FreeBSD Links KDE FreeBSD =20 URL: https://freebsd.kde.org/ KDE Community FreeBSD=20 URL: https://community.kde.org/FreeBSD Contact: Adriaan de Groot The KDE on FreeBSD project aims to package all of the software produced by the KDE Community for the FreeBSD ports tree. The software includes a full desktop environment called KDE Plasma, an IDE with the name KDevelop, a PIM suite known as Kontact and hundreds of other applications that can be used on any FreeBSD machine. With the continuation of the ever-so-peculiar era of almost-only-online, the KDE community has shifted gears and also gone for online events. The yearly conference, Akademy, was conducted online over video calls. Meanwhile, software continues to be released, so this quarter the kde@ team: * Put the beta of the next version of KDE Plasma, scheduled for official release in October 2020, into the Area51 development tree. Area51 is a fork of the FreeBSD ports tree where new development for KDE ports happens. * The monthly regular updates to the KDE Plasma desktop landed on-time and safely. * With three months in a quarter, there were also three releases of KDE Frameworks 5, including a new framework for handling DAV jobs. * The June applications update and its .1 release landed a bit late, but brings with it the usual raft of updates to KDE applications and libraries, * A new Digikam release, which arrived in the ports tree on the day of its release. * A new KDevelop release arrived a day after its release. This update contains a number of crash fixes for refactoring support. * Qt was updated to Qt 5.15, the last in the Qt5 series and an LTS version. Bugfix releases are expected, but the next major Qt will be Qt 6. On the infrastructure front, August saw some minor updates to CMake and ninja. As usual, kde@ continues to support the work of xorg@ and gnome@ in maintaining the Free Desktop stack on FreeBSD, including XOrg, poppler, and xdg-utils. A new MAINTAINER group, desktop@, has been created to provide shared ownership of that shared stack. With Python2 deprecation looming, the build system for QtWebEngine -- itself a fork of Chromium -- is becoming a pressing issue in Q4 and will no doubt chew up a lot of time in the coming months. __________________________________________________________________ Documentation Noteworthy changes in the documentation tree, in manpages, or in external books/documents. DOCNG on FreeBSD Links DOCNG Website Repo=20 URL: https://gitlab.com/carlavilla/freebsd-hugo-website DOCNG Documentation Repo=20 URL: https://gitlab.com/carlavilla/freebsd-hugo-documentation DOCNG Share Repo=20 URL: https://gitlab.com/carlavilla/freebsd-hugo-data Contact: Sergio Carlavilla The Doc New Generation project aims to convert the website and all existing documentation to Hugo/AsciiDoctor. Right now almost everything is converted as you can see in the repositories. The objective of using Hugo and AsciiDoctor is to reduce the learning curve and let people to start quickly with our documentation system. Other benefits of using Hugo is that we can use other technologies aside from AsciiDoctor, like MarkDown, RST, Pandoc, etc. The remaining tasks include: * Finish the conversion of some books to AsciiDoctor. * Get some tweaks in the CSS to be responsive. * Add AsciiDoctor extensions to create an index of tables and figures. * Make a general review. The dates for making the migration have yet to be discussed. Patches, comments and objections are always welcome. __________________________________________________________________ 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. Potluck - Flavour & Image Repository for pot Links Potluck Repository & Project=20 URL: https://potluck.honeyguide.net/ Potluck on github =20 URL: https://github.com/hny-gd/potluck pot project =20 URL: https://pot.pizzamig.dev Contact: <> pot is a jail management tool that also supports orchestration through nomad. Potluck aims to be to FreeBSD and pot what Dockerhub is to Linux and Docker: A repository of pot flavours and complete images for usage with pot. In the last quarter, an initial set of Nomad, Consul and Traefik images has been created that are sufficient to run a simple virtual datacenter out of the box. A three-part article series explaining how to set this up is also available now. Furthermore, ready-made images suitable for scheduling via Nomad and Consul in such an environment have been created, e.g. a BackupPC or a Postfix Backup MX service. Future plans include additional images and exposing more configuration options in the existing images to allow a more flexible usage. Beside general feedback and tests, additional flavours and patches are very welcome! Sponsors: Honeyguide GmbH & Honeyguide Group (Pty) Ltd ## Puppet Puppet Puppet's FreeBSD slack channel Bolt Choria Puppet Team puppet@FreeBSD.org Since out last status report a few years ago, the puppet@ team regularly updated the various Puppet ports to follow upstream releases of Puppet 4, Puppet 5 and Puppet 6. Puppet 4 was removed when it reached EOL. More recently, an effort was made to enhance Facter 4 so that it can be used as a drop-in replacement of Facter 3 on FreeBSD. Facter 4 is a Ruby rewrite of Facter 3, the C++ rewrite of Facter 2 which was initially in Ruby. As a consequence we have two ports for Facter: sysutils/facter is the C++ implementation (Facter 3) and sysutils/rubygems-facter is the Ruby implementation (updated from Facter 2 to Facter 4 a few weeks ago). The Puppet 5 and Puppet 6 ports already allow to choose which version of Facter to use. Facter 4 will be the default version of Facter with Puppet 7 which is expected to be released soon. We are getting ready to add a port for Puppet 7 as sysutils/puppet7 when it is available, along with PuppetServer 7 (sysutils/puppetserver7), and PuppetDB 7 (databases/puppetdb7). Regarding orchestration, most Marionette Collective ports have been deprecated for a long time, and the last component sysutils/mcollective is expected to be deprecated soon: Marionette Collective was not shipped anymore with Puppet 6 and Bolt has been made available as a lightweight replacement. Bolt is already available in the ports tree as sysutils/rubygems-bolt), but if you are using Marionette Collective, you are invited to look into Choria which will reach the ports tree soon as sysutils/choria. Choria is a direct evolution of Marionette Collective allowing a smooth transition from MCollective. Once Choria is available in the ports tree, Marionette Collective will be deprecated. __________________________________________________________________ News Home | Status Home Site Map | Legal Notices | =C2=A9 1995-2020 The FreeBSD Project. All rig= hts reserved. --u3hngvn2nte45ec7 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAABCgB9FiEEDonNJPbg/JLIMoS6Ps5hSHzN87oFAl+QsRhfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDBF ODlDRDI0RjZFMEZDOTJDODMyODRCQTNFQ0U2MTQ4N0NDREYzQkEACgkQPs5hSHzN 87pGWQf6AvmDxeRYsxL7wxau9nX/Vlg7G1OcEVVhIuJaZAGb+zItXHsDjiqScFAF Q/DH+8wf2F719Sxdp2AA844cAm1FktjERua6ZmjZtGXx89OPpZf9YfEiexzBJshX rW/a7Vl2kNhB9768wT6PhjB/LrRWi2vq7C5oyKCncD+K10DbdZsGm4ImiBvM8Oxn xGTRNvkpisukm4Fta0idrGIvnJj3w9Nlen6mKCXWCcYugdEnBtpV4Y2JZM6qaW78 WCCkPekA+YLIhaWBe4bmRswMeztPntllBD90XBiDRpeJ6NTxgiDdGMN1s9b3WtOC D0YYpR7nJXRLGbZvHIMfBzMu2TbGOg== =7BFi -----END PGP SIGNATURE----- --u3hngvn2nte45ec7-- From owner-freebsd-current@freebsd.org Wed Oct 21 23:53:00 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D802243326B for ; Wed, 21 Oct 2020 23:53:00 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-to1can01on0616.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe5d::616]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CGnP729Hlz3yrV for ; Wed, 21 Oct 2020 23:52:57 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kdjZVFBDjFz+n8Dp01p5cZRJhHRLG7CMeXTCp8y81wVJPdsG52/ukWIebFdO+POjCGESqi4guiUqiX1TqWPmoWDi9ISm+r4RzD4TSdC2QZuZX72ZtX5l4TEKOKIRcyo0rUNzj3t++u2Cu+HNh1oMXvCW/flmxTlO6on4PPiGDOEB5Xhz5sMAZSPdRCL/vS+xeJupWakVcufoD87O/MdfLQbl0irvJgcnfoprW1b8Wpt+m/GpFQ4wThDz8jlu0SfKJOtDHVpfyXN+bFKS3QFWijfFLvEzoD3YOW7isFA/sEApO5IT0oNY5ez7uZzVKRQS7P90hslu5/sJiESqu+bPkQ== 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-SenderADCheck; bh=LFLnxYNV5+b88mfM1Hjuj1aBy+f5XahYe/lZKc1bBIo=; b=TWBa02CfzGW9IVSuZ9jUKq41IXgBoLbOOe4MX1Jr2ojg1NvmwcfUqBvvI5xdZ5PYbQ/TmcsYATtWJxrCsjZKZVNV+gRo92chpHSLvIVdwM1Ycaz2N8yICOd0KH0yVChDwO7/e2UfEAEcQOjkqPwWA7t/DUPROs1wG9P4QjSduJ6A1ANlnYeaxvwzjEG6ofTEYl//eGHgmgO+7+/EjJi6I3QFhPGEw+26MxH81LzyCI600QoeVhIZDqXjSjxiXQXVPyLeUY1OwrkpYcYkk3M6rknxndAUm8UVEq+HlfmuPq4OjWudDA/Sq9hGI4GHDRs7MQLjP38JqNbcaUrSK3+IUw== 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 Received: from YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:24::27) by YTBPR01MB2944.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:19::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.18; Wed, 21 Oct 2020 23:52:52 +0000 Received: from YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM ([fe80::687f:d85a:a0a3:bd20]) by YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM ([fe80::687f:d85a:a0a3:bd20%6]) with mapi id 15.20.3499.018; Wed, 21 Oct 2020 23:52:52 +0000 From: Rick Macklem To: Mehmet Erol Sanliturk CC: Warner Losh , "freebsd-current@FreeBSD.org" Subject: Re: copyright notice question Thread-Topic: copyright notice question Thread-Index: AQHWpn7fxoWEd2ZfUkuqrM0B3buK/KmfuwkAgAGBL0+AAHXngIABBkqU Date: Wed, 21 Oct 2020 23:52:52 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: cbd4b2e5-500d-42d3-5d82-08d8761c6c94 x-ms-traffictypediagnostic: YTBPR01MB2944: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: GsW3kFLbZS0bHiDvNw/i2/38rjLY669wHJDow3RKWCTeIeJWYCgIQNGwt/uh2lf398NhCqNxsY1OLxLLB79Zyi66eU1Sg1Y+jUWYB1dYebhaObddJZyX0q1LIpXXV8sJevlX1VY5S+2M7eLKCquNVwcuFJi3as+cepCbfbh7QvAKXC1C5aAPCmhMXQQdvANyIN/BdVvUE8xKAG+bCkrVStvHZGZC5YcdrtMaj5QhbHcxXYvrv9vlkhn7yKzeEKNYMxrb7greAIIqvMO3iRj9fVfloAaiTt5a5V0fNt9etdLh9hYdmLwyzgLSVNHT6+Rxkx/2fTlpmHmbtq1/1zHK5w== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(39860400002)(136003)(376002)(366004)(396003)(346002)(66476007)(64756008)(76116006)(52536014)(66946007)(91956017)(66556008)(71200400001)(3480700007)(33656002)(86362001)(83380400001)(54906003)(5660300002)(66446008)(6916009)(786003)(15650500001)(4326008)(186003)(316002)(9686003)(8676002)(2906002)(8936002)(6506007)(55016002)(7696005)(478600001)(7116003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: N81wC0+1EsVgM8I2DDS8C/z9TwbLzmJV0A5+kyeleSxwEqt7lZmnxqLyhhxhy2LFtkZumJaEFJ5z/OQ/yVoelNTX9w/c6qTSk94afDTGc7uBQxlLpaqvhAjV3VAYMFUfekMLdClBNzKjstPyEM2xDcxQhtoB+zz3Sm1wf6kjeubDEpyTvavEuEXeAfVfbfjZcdsmndSpt0eEIO+JsWFK8E10lUECIuQ6hqOUm1L1/N/TiH25mRawW2fEItCwtzk69naFwL0BCzki/hx35Ic1v7eYtKOVK98ZllHHbcwuspTD2ZGsA8Jp90iEDlbaXLtUBmIRpk8/UBbMpbvkKN4pgq+1dL/tyII/gAI+CymlZUk3d1Ja98godtfwiqRLApxevV3v/H5rbnizZBA7R2X5yLqYzKlEJa/wn8+xbjC9Ua9HXkbSdaX9JuEy/ngpOsdvqJ61KQ/+IJf2/YOAMwlLs3uu5XhCHJOlsHDD/4IpcK9aPMRfCrDCWHwxHPY2eWyhaeuMY/xCTWCrjBSIx+PVG7iYsVQ+2Cx/iWUWib3W4mlctqf8SfQo4FAnvrN8UfAb4RZO8rqHokidJoZxo7JowmarmsCGQ8WBkKLadc7VTjBIXkFU3672m8jwkKSd8yNfs8gpHpP7/snEPTSumk19C+h5oghKcyGmz0XTuYxf7qwruoZk33JAAqVvQquRscMnBEqVv6eDDQ7YLRiELWvzzw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: cbd4b2e5-500d-42d3-5d82-08d8761c6c94 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Oct 2020 23:52:52.4480 (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: c6hQ94IxIOaS7TU4BRxIbR243nrabOgsV4/ZGlqInzWerrV0biqJ6JD+39RMJDdnTHRfV2pSy1j9XwXZQm+UOg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTBPR01MB2944 X-Rspamd-Queue-Id: 4CGnP729Hlz3yrV X-Spamd-Bar: ----- X-Spamd-Result: default: False [-5.97 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.984]; R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector1]; 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)[+ip6:2a01:111:f400::/48]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.001]; 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]; NEURAL_HAM_SHORT(-0.98)[-0.983]; 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:8075, ipnet:2a01:111:f000::/36, country:US]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2020 23:53:00 -0000 Mehmet Erol Sanliturk wrote:=0A= >On Wed, Oct 21, 2020 at 4:04 AM Rick Macklem > wrote:=0A= >>Warner Losh wrote:=0A= >>>On Mon, Oct 19, 2020, 7:25 PM Rick Macklem >> wrote:=0A= >>>>I'll admit I've hesitated to ask this for a long time, but I guess I ha= ve to;-)=0A= >>>>I've created two daemons for NFS-over-TLS, using the code in=0A= >>>>/usr/src/usr.sbin/gssd/gssd.c as a starting point.=0A= >>>>--> As such, I left the copyright notice from this file on the two file= s.=0A= >>>> (As you can see, it is a 2 clause FreeBSD one, so the terms aren'= t=0A= >>>> an issue.)=0A= >>>>=0A= >>>>What I am wondering is if I should be adding my name to it as an=0A= >>>>additional author or something like that?=0A= >>>>(I don't care, but it does seem a little weird that the copyright is he= ld=0A= >>>> by Isilon Inc, since I have no connection to them.)=0A= >>>=0A= >>>Likely. If you changed a substantial amount, then yes. The rule of thumb= is >50%=0A= >>> is no brainer yes. Smaller percentages require more nuanced judgement a= s to whether the changes are substantial enough to create a new work. Chanc= es are=0A= >>> quite good you fall into one of those categories. Also, if you have rep= laced more=0A= >>>than ~90% chances are good no original work remains. Again, a judgement = call.=0A= >>>There are more technical legal guidelines, but that would require a lawy= er.=0A= >>>=0A= >>>My hunch is that unless this is something far more trivial than I then I= 'd add the=0A= >>> notice, but retaining the old.=0A= >>Well, I'd guess it's somewhere in the 50->90% category.=0A= >>Would just adding a comment below the current copyright notice like:=0A= >>/*=0A= >> * Extensively modified from /usr/src/usr.sbin/gssd.c for RPC-over-TLS=0A= >> * by Rick Macklem.=0A= >> */=0A= >>be sufficient for the project, or should I put a second copyright notice= =0A= >>on it with my name on it? (This will seem odd, since it will have the sam= e=0A= >>terms as the extant one, but if that is what is appropriate for the proje= ct..)=0A= >>=0A= >>It is my understanding (I'm obviously not a lawyer, clearly indicated by = the=0A= >>size of my bank account;-) that a copyright notice can only be changed by= =0A= >>the holder (or with their express permission), but an additional copyrigh= t=0A= >>notice can be attached to the work to cover the re-write.=0A= >>Is this correct? (All amateur lawyers, feel free to respond;-)=0A= >>=0A= >>Thanks for your comments, rick=0A= >>=0A= >>>Warnet=0A= >>=0A= [copyright comment snipped]=0A= >My opinion is as follows :=0A= >=0A= >At the top of the related sources I would include a message ( approximatel= y ) as >follows :=0A= I believe for FreeBSD this would need to be after the main copyright notice= ,=0A= but that is trivial, I think?=0A= =0A= =0A= >After svn ( or git ) modification number(s) ... ( including ) I have mad= e substantial ( or significant ) modifications ( or improvements ) .=0A= >The copyright of these modifications with the present license listed below= are >belong to=0A= >=0A= >Rick Macklem , starting from date .....=0A= > ( Rick Macklem ... an approximately fixed address ... )=0A= Does anyone know if there are examples of this in other major open=0A= source projects?=0A= =0A= I would be very shy of creating a notice that is not exactly what other=0A= FreeBSD files have in them. For one thing, is referring to license terms in= another=0A= copyright notice "standard practice"?=0A= =0A= I'll admit that, unless there are examples of this elsewhere in the FreeBSD= =0A= source tree (or at least in other major open source projects), I would not = be=0A= comfortable doing this.=0A= =0A= Maybe I'll try asking this question...=0A= Is there a concern that the copyright notice that is on gssd.c could be con= sidered=0A= "not valid" due to the extensive changes made to the code by me?=0A= (If the answer to that is "no", then I don't see that anything needs to be = done,=0A= since the notice includes reasonable terms as already used elsewhere in Fr= eeBSD.=0A= I have no interest in being a copyright holder for this unless the copyrig= ht can=0A= be invalidated.)=0A= Put another way, "Is there a concern that the extensive changes would allow= the=0A= copyright notice be replaced by something like a GPL ?".=0A= =0A= rick, who would rather just lease the notice alone=0A= =0A= =0A= =0A= Each contributor may append such notifications listed on the topmost part .= =0A= When a person reads such sources , she/he very easily understands its modif= ication and copyright status without any doubt .=0A= =0A= =0A= Mehmet Erol Sanliturk=0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= =0A= From owner-freebsd-current@freebsd.org Thu Oct 22 00:05:08 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 31178434115 for ; Thu, 22 Oct 2020 00:05:08 +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 "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CGng71hc7z40XT for ; Thu, 22 Oct 2020 00:05:06 +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 09M054K2077403 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 21 Oct 2020 17:05:04 -0700 (PDT) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id 09M054sa077402; Wed, 21 Oct 2020 17:05:04 -0700 (PDT) (envelope-from jmg) Date: Wed, 21 Oct 2020 17:05:04 -0700 From: John-Mark Gurney To: Rick Macklem Cc: Warner Losh , "freebsd-current@FreeBSD.org" Subject: Re: copyright notice question Message-ID: <20201022000504.GJ8272@funkthat.com> Mail-Followup-To: Rick Macklem , Warner Losh , "freebsd-current@FreeBSD.org" References: 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]); Wed, 21 Oct 2020 17:05:04 -0700 (PDT) X-Rspamd-Queue-Id: 4CGng71hc7z40XT X-Spamd-Bar: / X-Spamd-Result: default: False [0.16 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[jmg]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; RCVD_TLS_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[funkthat.com]; AUTH_NA(1.00)[]; MID_RHS_MATCH_FROM(0.00)[]; NEURAL_HAM_LONG(-0.45)[-0.451]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.12)[-0.117]; NEURAL_HAM_MEDIUM(-0.47)[-0.474]; 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]; MAILMAN_DEST(0.00)[freebsd-current]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2020 00:05:08 -0000 Rick Macklem wrote this message on Wed, Oct 21, 2020 at 01:03 +0000: > Warner Losh wrote: > >On Mon, Oct 19, 2020, 7:25 PM Rick Macklem > wrote: > >>I'll admit I've hesitated to ask this for a long time, but I guess I have to;-) > >>I've created two daemons for NFS-over-TLS, using the code in > >>/usr/src/usr.sbin/gssd/gssd.c as a starting point. > >>--> As such, I left the copyright notice from this file on the two files. > >> (As you can see, it is a 2 clause FreeBSD one, so the terms aren't > >> an issue.) > >> > >>What I am wondering is if I should be adding my name to it as an > >>additional author or something like that? > >>(I don't care, but it does seem a little weird that the copyright is held > >> by Isilon Inc, since I have no connection to them.) > >> > >Likely. If you changed a substantial amount, then yes. The rule of thumb is >50% > > is no brainer yes. Smaller percentages require more nuanced judgement as to whether the changes are substantial enough to create a new work. Chances are > > quite good you fall into one of those categories. Also, if you have replaced more > >than ~90% chances are good no original work remains. Again, a judgement call. > >There are more technical legal guidelines, but that would require a lawyer. > > > >My hunch is that unless this is something far more trivial than I then I'd add the > > notice, but retaining the old. > Well, I'd guess it's somewhere in the 50->90% category. > Would just adding a comment below the current copyright notice like: > /* > * Extensively modified from /usr/src/usr.sbin/gssd.c for RPC-over-TLS > * by Rick Macklem. > */ > be sufficient for the project, or should I put a second copyright notice > on it with my name on it? (This will seem odd, since it will have the same > terms as the extant one, but if that is what is appropriate for the project..) I'd add both the above notice, but also your own copyright at the top... You don't need to add your own copyright, but if you do, the by Rick Macklem isn't needed in the modified from notice (and IMO, an unnecessary distraction)... The fact that you did the initial modifications will be apparent in the SVN/git history. -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-current@freebsd.org Thu Oct 22 05:55:13 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5CB4643EECC for ; Thu, 22 Oct 2020 05:55:13 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-oo1-xc31.google.com (mail-oo1-xc31.google.com [IPv6:2607:f8b0:4864:20::c31]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CGxR44DLXz4NcS for ; Thu, 22 Oct 2020 05:55:12 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: by mail-oo1-xc31.google.com with SMTP id c10so84154oon.6 for ; Wed, 21 Oct 2020 22:55:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sDxNr3yIJQgKHACYwXWdUYtQq/1XyH29+406rjwtRcY=; b=Vn7/L1fqBzFhePWgmlCmdnPaVnvqm51KKOEBnlhH1Afgti300Cwl8W0t0+Zcy3DKsx NkBP1HYqBPw2b0RCkuVF+exL2FGYhKvYOn+JuLVWd9rAGTIdf80h5GvWXqS8v8ubxLqY cwOwThIyvcpoa76faNtA7fxreYyuJObfDxuGem5VFpVhip9SsYR5DYv8aGdgllgxV7LH Ylt9mI0h9ZQzvWKQwNmpLhSF3R9Ln6R2Z76jL4DL+1Bfe28b8X+/2siDL69PH4HRNsu5 ivb2QN7LTRnMpJNY6zTffjodgdSLswX47jgoftvdfCUCmsuBBSyvR6GeYVj/nQXQlihX VM7A== X-Gm-Message-State: AOAM531KyOHNR61Cy3YQwDtKEdgXMbdGTouz6bdWqpCjtadTZTbxylW4 GlcB0smfywpXCCLENi1R97Wea/e4jhvkxEXsEQU= X-Google-Smtp-Source: ABdhPJwo8M6GCfdfThPb7JkGCD7uRKQDwjLgal2DQDOsm8fVTpupv1Dslqwsj+IYnPXA74sFf+eHWyvde+ib2+iWAqE= X-Received: by 2002:a4a:b78f:: with SMTP id a15mr803383oop.33.1603346111230; Wed, 21 Oct 2020 22:55:11 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Mehmet Erol Sanliturk Date: Thu, 22 Oct 2020 08:54:33 +0300 Message-ID: Subject: Re: copyright notice question To: Rick Macklem Cc: Warner Losh , "freebsd-current@FreeBSD.org" X-Rspamd-Queue-Id: 4CGxR44DLXz4NcS X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.06 / 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]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.03)[-1.034]; 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.02)[-1.015]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.01)[-1.009]; 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::c31:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2020 05:55:13 -0000 On Thu, Oct 22, 2020 at 2:52 AM Rick Macklem wrote: > Mehmet Erol Sanliturk wrote: > >On Wed, Oct 21, 2020 at 4:04 AM Rick Macklem > wrote: > >>Warner Losh wrote: > >>>On Mon, Oct 19, 2020, 7:25 PM Rick Macklem rmacklem@uoguelph.ca>>> wrote: > >>>>I'll admit I've hesitated to ask this for a long time, but I guess I > have to;-) > >>>>I've created two daemons for NFS-over-TLS, using the code in > >>>>/usr/src/usr.sbin/gssd/gssd.c as a starting point. > >>>>--> As such, I left the copyright notice from this file on the two > files. > >>>> (As you can see, it is a 2 clause FreeBSD one, so the terms > aren't > >>>> an issue.) > >>>> > >>>>What I am wondering is if I should be adding my name to it as an > >>>>additional author or something like that? > >>>>(I don't care, but it does seem a little weird that the copyright is > held > >>>> by Isilon Inc, since I have no connection to them.) > >>> > >>>Likely. If you changed a substantial amount, then yes. The rule of > thumb is >50% > >>> is no brainer yes. Smaller percentages require more nuanced judgement > as to whether the changes are substantial enough to create a new work. > Chances are > >>> quite good you fall into one of those categories. Also, if you have > replaced more > >>>than ~90% chances are good no original work remains. Again, a judgement > call. > >>>There are more technical legal guidelines, but that would require a > lawyer. > >>> > >>>My hunch is that unless this is something far more trivial than I then > I'd add the > >>> notice, but retaining the old. > >>Well, I'd guess it's somewhere in the 50->90% category. > >>Would just adding a comment below the current copyright notice like: > >>/* > >> * Extensively modified from /usr/src/usr.sbin/gssd.c for RPC-over-TLS > >> * by Rick Macklem. > >> */ > >>be sufficient for the project, or should I put a second copyright notice > >>on it with my name on it? (This will seem odd, since it will have the > same > >>terms as the extant one, but if that is what is appropriate for the > project..) > >> > >>It is my understanding (I'm obviously not a lawyer, clearly indicated by > the > >>size of my bank account;-) that a copyright notice can only be changed by > >>the holder (or with their express permission), but an additional > copyright > >>notice can be attached to the work to cover the re-write. > >>Is this correct? (All amateur lawyers, feel free to respond;-) > >> > >>Thanks for your comments, rick > >> > >>>Warnet > >> > [copyright comment snipped] > >My opinion is as follows : > > > >At the top of the related sources I would include a message ( > approximately ) as >follows : > > I believe for FreeBSD this would need to be after the main copyright > notice, > but that is trivial, I think? > > > A "Copyright owner additions Style Guide" may be prepared by the FreeBSD Project to make a common application pattern for such inclusions . A commonly accepted and applied style is the best over time . > >After svn ( or git ) modification number(s) ... ( including ) I have > made substantial ( or significant ) modifications ( or improvements ) . > >The copyright of these modifications with the present license listed > below are >belong to > > > >Rick Macklem , starting from date ..... > > ( Rick Macklem ... an approximately fixed address ... ) > Does anyone know if there are examples of this in other major open > source projects? > > I would be very shy of creating a notice that is not exactly what other > FreeBSD files have in them. For one thing, is referring to license terms > in another > copyright notice "standard practice"? > > I'll admit that, unless there are examples of this elsewhere in the FreeBSD > source tree (or at least in other major open source projects), I would not > be > comfortable doing this. > > Maybe I'll try asking this question... > Is there a concern that the copyright notice that is on gssd.c could be > considered > "not valid" due to the extensive changes made to the code by me? > (If the answer to that is "no", then I don't see that anything needs to be > done, > since the notice includes reasonable terms as already used elsewhere in > FreeBSD. > I have no interest in being a copyright holder for this unless the > copyright can > be invalidated.) > Put another way, "Is there a concern that the extensive changes would > allow the > copyright notice be replaced by something like a GPL ?". > > rick, who would rather just lease the notice alone > > Please consider zLib License : https://en.wikipedia.org/wiki/Zlib_License zlib License Inclusion of such modification information into modified sources is compulsory . One point is obvious : Modifications into a previously copyrighted source ( work ) either does NOT invalidate the previous copyright of the work or can NOT change its license . New additions may be included by a separate license , for example GPL , but the new license is applicable only to the NEW additions . I will not remember such an example , but , surely I can say that I am seeing many sources with such modification licenses , because I am tracking a large number of software repositories or I am encountering such sources during my open source software searches . No one is obliged to accept or use such sources because any one may use/start original licensed sources . My suggestion to include SVN ( or GIT ) number(s) is to eliminate searches to find copyright affected first copy . > > Each contributor may append such notifications listed on the topmost part . > When a person reads such sources , she/he very easily understands its > modification and copyright status without any doubt . > > > Mehmet Erol Sanliturk > > > > > > > > From owner-freebsd-current@freebsd.org Thu Oct 22 07:39:37 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 82D15440A68; Thu, 22 Oct 2020 07:39:37 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from relay4-d.mail.gandi.net (relay4-d.mail.gandi.net [217.70.183.196]) (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 4CGzlX39Z4z4V76; Thu, 22 Oct 2020 07:39:36 +0000 (UTC) (envelope-from avg@FreeBSD.org) X-Originating-IP: 93.72.151.96 Received: from [192.168.0.88] (east.meadow.volia.net [93.72.151.96]) (Authenticated sender: andriy.gapon@uabsd.com) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 39CBFE0018; Thu, 22 Oct 2020 07:39:26 +0000 (UTC) Subject: Re: Zpool doesn't boot anymore after FreeBSD 12.1 To: Cassiano Peixoto , freebsd-stable@freebsd.org, freebsd-current@freebsd.org References: From: Andriy Gapon Openpgp: preference=signencrypt Autocrypt: addr=avg@FreeBSD.org; keydata= mDMEX1iFDhYJKwYBBAHaRw8BAQdAiu8JG/oLFkVkOAJqJc7Dx5KI/Q6C3SBI20EQm+DXnAu0 HkFuZHJpeSBHYXBvbiA8YXZnQEZyZWVCU0Qub3JnPoiWBBMWCAA+FiEEyCHHZM09l0OE3Ir/ 1A1+Gq8+L1EFAl9YhQ4CGwMFCQeEzgAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQ1A1+ Gq8+L1Fc0wD/ZjmhHfbCJywZU3aOxXIPjcz73FYEGMvqMCCLAWyLbSABALFL+1ZNrjV3BGjq 889cOYFuboA/Yn3eWezS+tfqYBsGuDgEX1iFDhIKKwYBBAGXVQEFAQEHQL6B20Xi600TrkpG P9fWjl7JtHNxqrHKhX6Kg7kgb4ILAwEIB4h+BBgWCAAmFiEEyCHHZM09l0OE3Ir/1A1+Gq8+ L1EFAl9YhQ4CGwwFCQeEzgAACgkQ1A1+Gq8+L1F3cgEAktp4h+IJUJxL1vn6zMOt//znni/J TanKfQuA8wGXcGkBAKpZJhqMkg+pKk7MGvJhgJ6nCpTZ+rMK6vZVZLUWc3QF Message-ID: Date: Thu, 22 Oct 2020 10:39:26 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Firefox/60.0 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4CGzlX39Z4z4V76 X-Spamd-Bar: / X-Spamd-Result: default: False [0.00 / 15.00]; local_wl_from(0.00)[FreeBSD.org]; ASN(0.00)[asn:29169, ipnet:217.70.176.0/20, country:FR] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2020 07:39:37 -0000 On 21/10/2020 15:20, Cassiano Peixoto wrote: > Hi there, > > Anyone can help please? I've many servers with this same issue. Thanks Can you try to replace /boot/zfsloader with zfsloader from other FreeBSD versions? E.g., 12.0, 12.2-RC, 11.4, recent snapshot of the CURRENT? > On Fri, Oct 16, 2020 at 10:24 AM Cassiano Peixoto > wrote: > >> Hi there, >> >> I have a FreeBSD 12.1-STABLE running on VMWARE with one disk. Then I added two more disks to expand my pool. BTW I already did it many time with no issues. >> >> I ran: >> >> # zpool status >> pool: zroot >> state: ONLINE >> 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. >> scan: none requested >> config: >> >> NAME STATE READ WRITE CKSUM >> zroot ONLINE 0 0 0 >> gpt/disk0 ONLINE 0 0 0 >> >> errors: No known data errors >> >> # zpool add -f zroot da1 >> # zpool add -f zroot da2 >> # zpool status >> pool: zroot >> state: ONLINE >> scan: none requested >> config: >> >> NAME STATE READ WRITE CKSUM >> zroot ONLINE 0 0 0 >> gpt/disk0 ONLINE 0 0 0 >> da1 ONLINE 0 0 0 >> da2 ONLINE 0 0 0 >> >> errors: No known data errors >> # reboot >> >> Then my system doesn’t boot anymore, i got the following error: >> >> gptzfsboot: error 4 lba 2038346899 >> gptzfsboot: error 4 lba 1361327267 >> /boot/config: -Dh >> >> BTX loader 1.00 BTX version is 1.02 >> Consoles: internal video/keyboard serial port >> BIOS drive A: is fd0 >> BIOS drive C: is disk0 >> BIOS drive D: is disk1 >> BIOS drive E: is disk2 >> BIOS drive F: is disk3 >> BIOS drive G: is disk4 >> BIOS drive H: is disk5 >> ZFS: i/o error - all block copies unavailable >> ZFS: failed to read pool zroot directory object >> BIOS 638kB/3143616kB available memory >> >> FreeBSD/x86 bootstrap loader, Revision 1.1 >> ERROR: cannot open /boot/lua/loader.lua: invalid argument. >> >> Type '?' for list of commands, 'help' for more datailed help. >> OK >> >> I can import my pool with no problems using the lived, but I could not fix it. >> >> Seems a bug after 12.1-STABLE. Please, anyone can take a look ok that? >> >> Thanks. >> >> >> >> > _______________________________________________ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-current@freebsd.org Thu Oct 22 09:43:57 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B5CA8443B6F for ; Thu, 22 Oct 2020 09:43:57 +0000 (UTC) (envelope-from tsoome@me.com) Received: from pv50p00im-ztdg10021801.me.com (pv50p00im-ztdg10021801.me.com [17.58.6.56]) (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 4CH2W05gkSz4dV5 for ; Thu, 22 Oct 2020 09:43:56 +0000 (UTC) (envelope-from tsoome@me.com) Received: from nazgul.lan (148-52-235-80.sta.estpak.ee [80.235.52.148]) by pv50p00im-ztdg10021801.me.com (Postfix) with ESMTPSA id 459F0360098; Thu, 22 Oct 2020 09:43:54 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Subject: Re: Zpool doesn't boot anymore after FreeBSD 12.1 From: Toomas Soome In-Reply-To: Date: Thu, 22 Oct 2020 12:43:51 +0300 Cc: freebsd-stable , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <779972FA-1EFD-4B10-A7E2-C1D91B83DA31@me.com> References: To: Cassiano Peixoto X-Mailer: Apple Mail (2.3608.120.23.2.4) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.737 definitions=2020-10-22_03:2020-10-20, 2020-10-22 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-2006250000 definitions=main-2010220063 X-Rspamd-Queue-Id: 4CH2W05gkSz4dV5 X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.98 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[17.58.6.56:from]; 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(-0.51)[-0.512]; 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.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(-0.97)[-0.972]; 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)[-0.996]; MIME_GOOD(-0.10)[text/plain]; RECEIVED_SPAMHAUS_PBL(0.00)[80.235.52.148:received]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[17.58.6.56:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2020 09:43:57 -0000 There are few issues. with vmware, you should rather grow existing boot = disk - just to keep setup simple. If you are adding disks, make sure = they are properly partitioned. int13 error code 4 should be =E2=80=99sector not found=E2=80=99, I have = no idea why are you getting this one, but clearly there is something = wrong. I would fix this by adding new properly sized disk, boot from iso/usb = and create new zroot pool and copy data over from old and move old one = away. once you have verified boot from new zroot, you can clean up. rgds, toomas > On 22. Oct 2020, at 10:39, Andriy Gapon wrote: >=20 > On 21/10/2020 15:20, Cassiano Peixoto wrote: >> Hi there, >>=20 >> Anyone can help please? I've many servers with this same issue. = Thanks >=20 > Can you try to replace /boot/zfsloader with zfsloader from other = FreeBSD versions? > E.g., 12.0, 12.2-RC, 11.4, recent snapshot of the CURRENT? >=20 >> On Fri, Oct 16, 2020 at 10:24 AM Cassiano Peixoto = >> wrote: >>=20 >>> Hi there, >>>=20 >>> I have a FreeBSD 12.1-STABLE running on VMWARE with one disk. Then I = added two more disks to expand my pool. BTW I already did it many time = with no issues. >>>=20 >>> I ran: >>>=20 >>> # zpool status >>> pool: zroot >>> state: ONLINE >>> 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. >>> scan: none requested >>> config: >>>=20 >>> NAME STATE READ WRITE CKSUM >>> zroot ONLINE 0 0 0 >>> gpt/disk0 ONLINE 0 0 0 >>>=20 >>> errors: No known data errors >>>=20 >>> # zpool add -f zroot da1 >>> # zpool add -f zroot da2 >>> # zpool status >>> pool: zroot >>> state: ONLINE >>> scan: none requested >>> config: >>>=20 >>> NAME STATE READ WRITE CKSUM >>> zroot ONLINE 0 0 0 >>> gpt/disk0 ONLINE 0 0 0 >>> da1 ONLINE 0 0 0 >>> da2 ONLINE 0 0 0 >>>=20 >>> errors: No known data errors >>> # reboot >>>=20 >>> Then my system doesn=E2=80=99t boot anymore, i got the following = error: >>>=20 >>> gptzfsboot: error 4 lba 2038346899 >>> gptzfsboot: error 4 lba 1361327267 >>> /boot/config: -Dh >>>=20 >>> BTX loader 1.00 BTX version is 1.02 >>> Consoles: internal video/keyboard serial port >>> BIOS drive A: is fd0 >>> BIOS drive C: is disk0 >>> BIOS drive D: is disk1 >>> BIOS drive E: is disk2 >>> BIOS drive F: is disk3 >>> BIOS drive G: is disk4 >>> BIOS drive H: is disk5 >>> ZFS: i/o error - all block copies unavailable >>> ZFS: failed to read pool zroot directory object >>> BIOS 638kB/3143616kB available memory >>>=20 >>> FreeBSD/x86 bootstrap loader, Revision 1.1 >>> ERROR: cannot open /boot/lua/loader.lua: invalid argument. >>>=20 >>> Type '?' for list of commands, 'help' for more datailed help. >>> OK >>>=20 >>> I can import my pool with no problems using the lived, but I could = not fix it. >>>=20 >>> Seems a bug after 12.1-STABLE. Please, anyone can take a look ok = that? >>>=20 >>> Thanks. >>>=20 >>>=20 >>>=20 >>>=20 >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to = "freebsd-stable-unsubscribe@freebsd.org" >>=20 >=20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Thu Oct 22 13:42:25 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id EC7B14490F1; Thu, 22 Oct 2020 13:42:25 +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 4CH7p934Bmz3f3Q; Thu, 22 Oct 2020 13:42:25 +0000 (UTC) (envelope-from avg@FreeBSD.org) X-Originating-IP: 93.72.151.96 Received: from [192.168.0.88] (east.meadow.volia.net [93.72.151.96]) (Authenticated sender: andriy.gapon@uabsd.com) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id 7F1321C0013; Thu, 22 Oct 2020 13:42:17 +0000 (UTC) Subject: Re: Zpool doesn't boot anymore after FreeBSD 12.1 To: Cassiano Peixoto Cc: freebsd-stable@freebsd.org, freebsd-current@freebsd.org References: From: Andriy Gapon Openpgp: preference=signencrypt Autocrypt: addr=avg@FreeBSD.org; keydata= mDMEX1iFDhYJKwYBBAHaRw8BAQdAiu8JG/oLFkVkOAJqJc7Dx5KI/Q6C3SBI20EQm+DXnAu0 HkFuZHJpeSBHYXBvbiA8YXZnQEZyZWVCU0Qub3JnPoiWBBMWCAA+FiEEyCHHZM09l0OE3Ir/ 1A1+Gq8+L1EFAl9YhQ4CGwMFCQeEzgAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQ1A1+ Gq8+L1Fc0wD/ZjmhHfbCJywZU3aOxXIPjcz73FYEGMvqMCCLAWyLbSABALFL+1ZNrjV3BGjq 889cOYFuboA/Yn3eWezS+tfqYBsGuDgEX1iFDhIKKwYBBAGXVQEFAQEHQL6B20Xi600TrkpG P9fWjl7JtHNxqrHKhX6Kg7kgb4ILAwEIB4h+BBgWCAAmFiEEyCHHZM09l0OE3Ir/1A1+Gq8+ L1EFAl9YhQ4CGwwFCQeEzgAACgkQ1A1+Gq8+L1F3cgEAktp4h+IJUJxL1vn6zMOt//znni/J TanKfQuA8wGXcGkBAKpZJhqMkg+pKk7MGvJhgJ6nCpTZ+rMK6vZVZLUWc3QF Message-ID: <33381216-498a-51ff-839c-da772c43b60e@FreeBSD.org> Date: Thu, 22 Oct 2020 16:42:16 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Firefox/60.0 Thunderbird/60.9.0 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: 4CH7p934Bmz3f3Q X-Spamd-Bar: / X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:29169, ipnet:217.70.176.0/20, country:FR]; local_wl_from(0.00)[FreeBSD.org] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2020 13:42:26 -0000 On 22/10/2020 16:39, Cassiano Peixoto wrote: > Hi Andriy, > > I've just tried copying my zfsloader from 11.2-STABLE (R350026) to FreeBSD 12.1 > and 12.2 (STABLE) and fixed the issue. > > I also tried to use zfsloader of 11.3 but didn't work and the same issue happened. > > So it seems that something has changed on zfsloader after 11.2 that brings this > issue. > > My question is: Should it be expected or is it a bug to be fixed? > In my opinion it's a bug. zfsloader should not require that disks must be partitioned. -- Andriy Gapon From owner-freebsd-current@freebsd.org Thu Oct 22 14:30:22 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 430A044A419 for ; Thu, 22 Oct 2020 14:30:22 +0000 (UTC) (envelope-from tsoome@me.com) Received: from pv50p00im-zteg10021401.me.com (pv50p00im-zteg10021401.me.com [17.58.6.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 4CH8sT3cTqz3yBq for ; Thu, 22 Oct 2020 14:30:21 +0000 (UTC) (envelope-from tsoome@me.com) Received: from nazgul.lan (148-52-235-80.sta.estpak.ee [80.235.52.148]) by pv50p00im-zteg10021401.me.com (Postfix) with ESMTPSA id 849734802B3; Thu, 22 Oct 2020 14:30:18 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Subject: Re: Zpool doesn't boot anymore after FreeBSD 12.1 From: Toomas Soome In-Reply-To: <33381216-498a-51ff-839c-da772c43b60e@FreeBSD.org> Date: Thu, 22 Oct 2020 17:30:16 +0300 Cc: Cassiano Peixoto , freebsd-stable@freebsd.org, freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <52294834-4BA0-4EC1-A392-6D338F138D54@me.com> References: <33381216-498a-51ff-839c-da772c43b60e@FreeBSD.org> To: Andriy Gapon X-Mailer: Apple Mail (2.3608.120.23.2.4) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.737 definitions=2020-10-22_10:2020-10-20, 2020-10-22 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-2006250000 definitions=main-2010220101 X-Rspamd-Queue-Id: 4CH8sT3cTqz3yBq X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.62 / 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:+]; DMARC_POLICY_ALLOW(-0.50)[me.com,quarantine]; NEURAL_HAM_SHORT(-0.12)[-0.119]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; 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)[-0.997]; R_DKIM_ALLOW(-0.20)[me.com:s=1a1hai]; FREEFALL_USER(0.00)[tsoome]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-1.01)[-1.008]; MIME_GOOD(-0.10)[text/plain]; RECEIVED_SPAMHAUS_PBL(0.00)[80.235.52.148:received]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[17.58.6.47:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[17.58.6.47:from]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2020 14:30:22 -0000 > On 22. Oct 2020, at 16:42, Andriy Gapon wrote: >=20 > On 22/10/2020 16:39, Cassiano Peixoto wrote: >> Hi Andriy, >>=20 >> I've just tried copying my zfsloader from 11.2-STABLE (R350026) to = FreeBSD 12.1 >> and 12.2 (STABLE) and fixed the issue. >>=20 >> I also tried to use zfsloader of 11.3 but didn't work and the same = issue happened. >>=20 >> So it seems that something has changed on zfsloader after 11.2 that = brings this >> issue. >>=20 >> My question is: Should it be expected or is it a bug to be fixed? >>=20 >=20 > In my opinion it's a bug. > zfsloader should not require that disks must be partitioned. >=20 maybe, maybe not. Anyhow you can only practice this with pc bios systems = and those systems will be gone. And the buggier the emulated bios = implementations are, the sooner this will happen=E2=80=A6. =20 But, since we now can determine usable disk size from zfs asize, we = actually can lift the limit, but that limit does not explain errors from = INT13.=20 So something else is going on there. And since there is no reason to = build complicated pool layout in virtual machine, I gave my suggestion. rgds, toomas From owner-freebsd-current@freebsd.org Thu Oct 22 17:37:51 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6535C44DB89; Thu, 22 Oct 2020 17:37:51 +0000 (UTC) (envelope-from sergey.dyatko@gmail.com) Received: from mail-lj1-x244.google.com (mail-lj1-x244.google.com [IPv6:2a00:1450:4864:20::244]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CHF1p4694z4Cfm; Thu, 22 Oct 2020 17:37:50 +0000 (UTC) (envelope-from sergey.dyatko@gmail.com) Received: by mail-lj1-x244.google.com with SMTP id h20so2818611lji.9; Thu, 22 Oct 2020 10:37:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=MhoOwATKEWNb+CUubFE0qpbga7DCwAufLRF1GI67eHc=; b=DVQylvZoymL3QvqhB5znWkJfQKqgi5MU6pI7/P+Fw3s8OVxFu6D/R9GdLpF0rVxLLy TJJUT4fUtbHyCVeWi9qq4ksHb/6k6BBnHjG7qzbjRHNJM110f92dTTpW37CCeRYwXLic sbcHZaVfKzTbTHonymcogvW9fsSkOKAmQUkBJIOgn5M3F9qSV6pPY+blVI1PMUpA0LkP G8+a9kSi1t0GZ7Evn0h4ap/WonqyLXUehAU5ztYcEZ5S1joCgWcSphLaQdedSjDKAQzS Y6Rukut1E4zFiwqqwxET3waWjz7IEirNH5r1IXH0m5Jbd8saNpIXryyXGR1Nwoa9upqW t2wQ== X-Gm-Message-State: AOAM5339QmtO1nF56RFiDZkJS3AGfoO7EcO/ZHbJ0rwFSAVeGsRCYgzr CS4sfQqVviOvqv4hHIcslrqXm47vs40= X-Google-Smtp-Source: ABdhPJzPieafJ/G5sump7HcpCI+vTgHuAIgI5rigXQEJtUGEy+kBKuOu1D/yawjJoq7RenHeU2PouQ== X-Received: by 2002:a2e:6e14:: with SMTP id j20mr1301609ljc.361.1603388268743; Thu, 22 Oct 2020 10:37:48 -0700 (PDT) Received: from laptop.domain (mm-223-241-125-178.mfilial.dynamic.pppoe.byfly.by. [178.125.241.223]) by smtp.gmail.com with ESMTPSA id j12sm388880ljg.22.2020.10.22.10.37.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Oct 2020 10:37:48 -0700 (PDT) Date: Thu, 22 Oct 2020 20:37:52 +0300 From: "Sergey V. Dyatko" To: freebsd-current@freebsd.org Cc: freebsd-stable@freebsd.org Subject: Re: Zpool doesn't boot anymore after FreeBSD 12.1 Message-ID: <20201022203752.36fb6f3f@laptop.domain> In-Reply-To: <33381216-498a-51ff-839c-da772c43b60e@FreeBSD.org> References: <33381216-498a-51ff-839c-da772c43b60e@FreeBSD.org> X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; amd64-portbld-freebsd13.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4CHF1p4694z4Cfm X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.36 / 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:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.41)[-0.406]; RECEIVED_SPAMHAUS_PBL(0.00)[178.125.241.223: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]; TAGGED_FROM(0.00)[]; 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=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.99)[-0.987]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::244:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-stable,freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2020 17:37:51 -0000 On Thu, 22 Oct 2020 16:42:16 +0300 Andriy Gapon wrote: > On 22/10/2020 16:39, Cassiano Peixoto wrote: > > Hi Andriy, > > > > I've just tried copying my zfsloader from 11.2-STABLE (R350026) to FreeBSD > > 12.1 and 12.2 (STABLE) and fixed the issue. > > > > I also tried to use zfsloader of 11.3 but didn't work and the same issue > > happened. > > > > So it seems that something has changed on zfsloader after 11.2 that brings > > this issue. > > > > My question is: Should it be expected or is it a bug to be fixed? > > > > In my opinion it's a bug. > zfsloader should not require that disks must be partitioned. > +1 That's why I have terribly outdated 13-CURRENT on bunch of servers and can't update them. Most of them look like this: [tiger@st25]:~>zpool status pool: st25 state: ONLINE scan: none requested config: NAME STATE READ WRITE CKSUM st25 ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 ada0 ONLINE 0 0 0 ada1 ONLINE 0 0 0 mirror-1 ONLINE 0 0 0 ada2 ONLINE 0 0 0 ada3 ONLINE 0 0 0 mirror-2 ONLINE 0 0 0 ada4 ONLINE 0 0 0 ada5 ONLINE 0 0 0 mirror-3 ONLINE 0 0 0 ada6 ONLINE 0 0 0 ada7 ONLINE 0 0 0 errors: No known data errors They haven't separate boot device and have from 7 to 30+ Tb of data that I can't backup anywhere for re-install server with disk partitioning. Some time ago I managed to get aroud this reverting 2 commits ( r342151 + don't remember revision) but then there where some other improvements after which I lost the opportunity to revert this commits -- wbr, Sergey From owner-freebsd-current@freebsd.org Thu Oct 22 20:04:16 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 1660A42954D for ; Thu, 22 Oct 2020 20:04:16 +0000 (UTC) (envelope-from tsoome@me.com) Received: from pv50p00im-hyfv10021501.me.com (pv50p00im-hyfv10021501.me.com [17.58.6.48]) (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 4CHJGk6XfYz4RjV for ; Thu, 22 Oct 2020 20:04:14 +0000 (UTC) (envelope-from tsoome@me.com) Received: from nazgul.lan (148-52-235-80.sta.estpak.ee [80.235.52.148]) by pv50p00im-hyfv10021501.me.com (Postfix) with ESMTPSA id 97948B405F5; Thu, 22 Oct 2020 20:04:11 +0000 (UTC) From: Toomas Soome Message-Id: <2E4B5AFC-C23E-4F33-8EFA-D285A998A4F0@me.com> Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Subject: Re: Zpool doesn't boot anymore after FreeBSD 12.1 Date: Thu, 22 Oct 2020 23:04:09 +0300 In-Reply-To: <20201022203752.36fb6f3f@laptop.domain> Cc: FreeBSD Current , freebsd-stable@freebsd.org To: "Sergey V. Dyatko" References: <33381216-498a-51ff-839c-da772c43b60e@FreeBSD.org> <20201022203752.36fb6f3f@laptop.domain> X-Mailer: Apple Mail (2.3608.120.23.2.4) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.737 definitions=2020-10-22_15:2020-10-20, 2020-10-22 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-2006250000 definitions=main-2010220131 X-Rspamd-Queue-Id: 4CHJGk6XfYz4RjV X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.74 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[me.com]; MV_CASE(0.50)[]; RWL_MAILSPIKE_GOOD(0.00)[17.58.6.48:from]; R_SPF_ALLOW(-0.20)[+ip4:17.58.0.0/16]; DKIM_TRACE(0.00)[me.com:+]; DMARC_POLICY_ALLOW(-0.50)[me.com,quarantine]; NEURAL_HAM_SHORT(-0.29)[-0.288]; 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)[]; DWL_DNSWL_NONE(0.00)[me.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.96)[-0.964]; 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(-0.99)[-0.992]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RECEIVED_SPAMHAUS_PBL(0.00)[80.235.52.148:received]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[17.58.6.48:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2020 20:04:16 -0000 Hi! Please try 366951:) I think, it should get things better for you. rgds, toomas > On 22. Oct 2020, at 20:37, Sergey V. Dyatko = wrote: >=20 > On Thu, 22 Oct 2020 16:42:16 +0300 > Andriy Gapon wrote:=20 >=20 >> On 22/10/2020 16:39, Cassiano Peixoto wrote: >>> Hi Andriy, >>>=20 >>> I've just tried copying my zfsloader from 11.2-STABLE (R350026) to = FreeBSD >>> 12.1 and 12.2 (STABLE) and fixed the issue. >>>=20 >>> I also tried to use zfsloader of 11.3 but didn't work and the same = issue >>> happened. >>>=20 >>> So it seems that something has changed on zfsloader after 11.2 that = brings >>> this issue. >>>=20 >>> My question is: Should it be expected or is it a bug to be fixed? >>>=20 >>=20 >> In my opinion it's a bug. >> zfsloader should not require that disks must be partitioned. >>=20 >=20 > +1 > That's why I have terribly outdated 13-CURRENT on bunch of servers and = can't > update them.=20 >=20 > Most of them look like this: > [tiger@st25]:~>zpool status > pool: st25 > state: ONLINE > scan: none requested > config: >=20 > NAME STATE READ WRITE CKSUM > st25 ONLINE 0 0 0 > mirror-0 ONLINE 0 0 0 > ada0 ONLINE 0 0 0 > ada1 ONLINE 0 0 0 > mirror-1 ONLINE 0 0 0 > ada2 ONLINE 0 0 0 > ada3 ONLINE 0 0 0 > mirror-2 ONLINE 0 0 0 > ada4 ONLINE 0 0 0 > ada5 ONLINE 0 0 0 > mirror-3 ONLINE 0 0 0 > ada6 ONLINE 0 0 0 > ada7 ONLINE 0 0 0 >=20 > errors: No known data errors >=20 > They haven't separate boot device and have from 7 to 30+ Tb of data = that I > can't backup anywhere for re-install server with disk partitioning. = Some time > ago I managed to get aroud this reverting 2 commits ( r342151 + don't > remember revision) but then there where some other improvements after = which I > lost the opportunity to revert this commits >=20 > -- > wbr, Sergey >=20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to = "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Thu Oct 22 20:34:50 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id DD1EE42A5D9; Thu, 22 Oct 2020 20:34:50 +0000 (UTC) (envelope-from sergey.dyatko@gmail.com) Received: from mail-ed1-x542.google.com (mail-ed1-x542.google.com [IPv6:2a00:1450:4864:20::542]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CHJy21Kwfz4TWZ; Thu, 22 Oct 2020 20:34:49 +0000 (UTC) (envelope-from sergey.dyatko@gmail.com) Received: by mail-ed1-x542.google.com with SMTP id x1so3099559eds.1; Thu, 22 Oct 2020 13:34:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=iRVBUuQ+c16gnVnu5vNwj1ts2E/pLp1XhrYJ1I3nDpY=; b=a2vyPBsZZe1OmNR0CKSgFgjR5HPdPHTdbDPbgqhb+K1mEREi1iNjtzb6fC8Ky9gFhQ 1pVMzNqLjC3cYPW/NDzmlhMWCRttUP+OVmuSGSvso/4VKuNs1Y1lQQkqajIpAJTC9MtX dyC3ca6BnCimzFFrsEfHFgEbQSOCD/ZSSv1N8bDlfNN3f9U6j+xBpHmmVK+9YZETwdv3 cdLQaaeChgn6ptkUCDy14WGkibfWM3tbOIDUZNToO76rCriSpnlikYcKhC7iDIDkqiPM CRFPf3tQcyjCQNFPCijQr18bzO+bXFdpcOtDC1yIrit9Ar/Ck/eAzrzaQPQYn094Sr3j OpJQ== X-Gm-Message-State: AOAM531Yw/Q+Wv3tFCJGdx+zN//qZuSf8Wymqx1aX7R8gjDbg7fzLOg9 QEoZGrslkvqPgSC166mR0jbPwTYkHac= X-Google-Smtp-Source: ABdhPJywIuMU1JC3EzVnOdMU6W9lHKz9AIXLQVbdIs5dr/cgu/8e582YE2SY6MSDlYPoX3mKzEVfdA== X-Received: by 2002:aa7:cc10:: with SMTP id q16mr3139205edt.96.1603398888672; Thu, 22 Oct 2020 13:34:48 -0700 (PDT) Received: from laptop.domain (mm-223-241-125-178.mfilial.dynamic.pppoe.byfly.by. [178.125.241.223]) by smtp.gmail.com with ESMTPSA id p16sm1385726ejz.103.2020.10.22.13.34.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Oct 2020 13:34:48 -0700 (PDT) Date: Thu, 22 Oct 2020 23:34:51 +0300 From: "Sergey V. Dyatko" To: Toomas Soome Cc: FreeBSD Current , freebsd-stable@freebsd.org Subject: Re: Zpool doesn't boot anymore after FreeBSD 12.1 Message-ID: <20201022233451.40a3aed6@laptop.domain> In-Reply-To: <2E4B5AFC-C23E-4F33-8EFA-D285A998A4F0@me.com> References: <33381216-498a-51ff-839c-da772c43b60e@FreeBSD.org> <20201022203752.36fb6f3f@laptop.domain> <2E4B5AFC-C23E-4F33-8EFA-D285A998A4F0@me.com> X-Mailer: Claws Mail 3.17.5 (GTK+ 2.24.32; amd64-portbld-freebsd13.0) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4CHJy21Kwfz4TWZ X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.32 / 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(-0.34)[-0.341]; FREEMAIL_TO(0.00)[me.com]; RECEIVED_SPAMHAUS_PBL(0.00)[178.125.241.223: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]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.97)[-0.973]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.004]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::542:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current,freebsd-stable] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2020 20:34:50 -0000 On Thu, 22 Oct 2020 23:04:09 +0300 Toomas Soome wrote: > Hi! > > Please try 366951:) I think, it should get things better for you. > > rgds, > toomas > Thanks! I'll try as soon as I can find 7-8Tb for backup :) btw, can I update my head@r324614 to 366951 at once ? > > On 22. Oct 2020, at 20:37, Sergey V. Dyatko wrote: > > > > On Thu, 22 Oct 2020 16:42:16 +0300 > > Andriy Gapon wrote: > > > >> On 22/10/2020 16:39, Cassiano Peixoto wrote: > >>> Hi Andriy, > >>> > >>> I've just tried copying my zfsloader from 11.2-STABLE (R350026) to FreeBSD > >>> 12.1 and 12.2 (STABLE) and fixed the issue. > >>> > >>> I also tried to use zfsloader of 11.3 but didn't work and the same issue > >>> happened. > >>> > >>> So it seems that something has changed on zfsloader after 11.2 that brings > >>> this issue. > >>> > >>> My question is: Should it be expected or is it a bug to be fixed? > >>> > >> > >> In my opinion it's a bug. > >> zfsloader should not require that disks must be partitioned. > >> > > > > +1 > > That's why I have terribly outdated 13-CURRENT on bunch of servers and can't > > update them. > > > > Most of them look like this: > > [tiger@st25]:~>zpool status > > pool: st25 > > state: ONLINE > > scan: none requested > > config: > > > > NAME STATE READ WRITE CKSUM > > st25 ONLINE 0 0 0 > > mirror-0 ONLINE 0 0 0 > > ada0 ONLINE 0 0 0 > > ada1 ONLINE 0 0 0 > > mirror-1 ONLINE 0 0 0 > > ada2 ONLINE 0 0 0 > > ada3 ONLINE 0 0 0 > > mirror-2 ONLINE 0 0 0 > > ada4 ONLINE 0 0 0 > > ada5 ONLINE 0 0 0 > > mirror-3 ONLINE 0 0 0 > > ada6 ONLINE 0 0 0 > > ada7 ONLINE 0 0 0 > > > > errors: No known data errors > > > > They haven't separate boot device and have from 7 to 30+ Tb of data that I > > can't backup anywhere for re-install server with disk partitioning. Some > > time ago I managed to get aroud this reverting 2 commits ( r342151 + don't > > remember revision) but then there where some other improvements after which > > I lost the opportunity to revert this commits > > > > -- > > wbr, Sergey > > > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- wbr, Sergey From owner-freebsd-current@freebsd.org Thu Oct 22 20:37:09 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9857442A9AC for ; Thu, 22 Oct 2020 20:37:09 +0000 (UTC) (envelope-from tsoome@me.com) Received: from pv50p00im-hyfv10021501.me.com (pv50p00im-hyfv10021501.me.com [17.58.6.48]) (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 4CHK0j0jHZz4TkX for ; Thu, 22 Oct 2020 20:37:08 +0000 (UTC) (envelope-from tsoome@me.com) Received: from nazgul.lan (148-52-235-80.sta.estpak.ee [80.235.52.148]) by pv50p00im-hyfv10021501.me.com (Postfix) with ESMTPSA id 49D0DB403E6; Thu, 22 Oct 2020 20:37:06 +0000 (UTC) From: Toomas Soome Message-Id: Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Subject: Re: Zpool doesn't boot anymore after FreeBSD 12.1 Date: Thu, 22 Oct 2020 23:37:04 +0300 In-Reply-To: Cc: "Sergey V. Dyatko" , freebsd-current@freebsd.org, freebsd-stable@freebsd.org To: Cassiano Peixoto References: <33381216-498a-51ff-839c-da772c43b60e@FreeBSD.org> <20201022203752.36fb6f3f@laptop.domain> X-Mailer: Apple Mail (2.3608.120.23.2.4) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.737 definitions=2020-10-22_15:2020-10-20, 2020-10-22 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-2006250000 definitions=main-2010220131 X-Rspamd-Queue-Id: 4CHK0j0jHZz4TkX X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.78 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:17.58.0.0/16:c]; FREEMAIL_FROM(0.00)[me.com]; RWL_MAILSPIKE_GOOD(0.00)[17.58.6.48:from]; MV_CASE(0.50)[]; DKIM_TRACE(0.00)[me.com:+]; DMARC_POLICY_ALLOW(-0.50)[me.com,quarantine]; NEURAL_HAM_SHORT(-0.32)[-0.317]; 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)[]; DWL_DNSWL_NONE(0.00)[me.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.96)[-0.962]; R_DKIM_ALLOW(-0.20)[me.com:s=1a1hai]; FREEFALL_USER(0.00)[tsoome]; 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.10)[multipart/alternative,text/plain]; RECEIVED_SPAMHAUS_PBL(0.00)[80.235.52.148:received]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[17.58.6.48:from]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Oct 2020 20:37:09 -0000 > On 22. Oct 2020, at 23:29, Cassiano Peixoto = wrote: >=20 >=20 > Hi Toomas, >=20 > Thank you for this patch. Can I know when it will be MFCed? I'd like = to try. MFC will take a bit because I need to bring it together with asize = updates, so we would need to do a bit of cherry-picking and testing. rgds, toomas >=20 >=20 >> Hi! >>=20 >> Please try 366951:) I think, it should get things better for you. >>=20 >> rgds, >> toomas > On Thu, Oct 22, 2020 at 3:04 PM Cassiano Peixoto = > wrote: > Sergey, >=20 > I agree with you. The best thing is to revert the commit on zfsloader. = Many people didn't realize this issue yet, but they will run into a big = problem soon. >=20 > On Thu, Oct 22, 2020 at 2:41 PM Sergey V. Dyatko = > wrote: > On Thu, 22 Oct 2020 16:42:16 +0300 > Andriy Gapon wrote:=20 >=20 > > On 22/10/2020 16:39, Cassiano Peixoto wrote: > > > Hi Andriy, > > >=20 > > > I've just tried copying my zfsloader from 11.2-STABLE (R350026) to = FreeBSD > > > 12.1 and 12.2 (STABLE) and fixed the issue. > > >=20 > > > I also tried to use zfsloader of 11.3 but didn't work and the same = issue > > > happened. > > >=20 > > > So it seems that something has changed on zfsloader after 11.2 = that brings > > > this issue. > > >=20 > > > My question is: Should it be expected or is it a bug to be fixed? > > > =20 > >=20 > > In my opinion it's a bug. > > zfsloader should not require that disks must be partitioned. > >=20 >=20 > +1 > That's why I have terribly outdated 13-CURRENT on bunch of servers and = can't > update them.=20 >=20 > Most of them look like this: > [tiger@st25]:~>zpool status > pool: st25 > state: ONLINE > scan: none requested > config: >=20 > NAME STATE READ WRITE CKSUM > st25 ONLINE 0 0 0 > mirror-0 ONLINE 0 0 0 > ada0 ONLINE 0 0 0 > ada1 ONLINE 0 0 0 > mirror-1 ONLINE 0 0 0 > ada2 ONLINE 0 0 0 > ada3 ONLINE 0 0 0 > mirror-2 ONLINE 0 0 0 > ada4 ONLINE 0 0 0 > ada5 ONLINE 0 0 0 > mirror-3 ONLINE 0 0 0 > ada6 ONLINE 0 0 0 > ada7 ONLINE 0 0 0 >=20 > errors: No known data errors >=20 > They haven't separate boot device and have from 7 to 30+ Tb of data = that I > can't backup anywhere for re-install server with disk partitioning. = Some time > ago I managed to get aroud this reverting 2 commits ( r342151 + don't > remember revision) but then there where some other improvements after = which I > lost the opportunity to revert this commits >=20 > -- > wbr, Sergey >=20 > _______________________________________________ > freebsd-stable@freebsd.org mailing = list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable = > To unsubscribe, send any mail to = "freebsd-stable-unsubscribe@freebsd.org = " From owner-freebsd-current@freebsd.org Fri Oct 23 02:02:34 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6DB48438AB0 for ; Fri, 23 Oct 2020 02:02:34 +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 "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CHSDB2Hnfz4kKL for ; Fri, 23 Oct 2020 02:02:34 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1354) id 3CC9A10E4B; Fri, 23 Oct 2020 02:02:34 +0000 (UTC) From: Jan Beich To: freebsd-current@freebsd.org Subject: uefi(8) fails to boot from ZFS with compression=zstd Date: Fri, 23 Oct 2020 04:02:31 +0200 Message-ID: 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=1603418554; 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=jvFgw/K8KtH3QlxCGJ8A8CnvyVHkjG7kVaR8FsNsstU=; b=q8OhJQ9Juoxu+zFvqJoi6E3+yNhJC3aU2CIsJ2RKp0flb04vt+h5HIrRRcI8jp84kh2AxG ZtMbG0RaQSMuxD6/0W1StwU2r4E10Z7a2sUotyKUHTrQUP2IFAiN/eVWQg/2TyK7u/J5wn vN2pXDJbzj60/OqYYl3oGE7Vqx52dhV4s8NBRR1IAIEuia5Jum6grZHEqlS02msEilOYIL bln0rfMWua+fXREwokbYlB12BF1z1P0Wqi/VqDoHyz0yst8o2sKoR60GWXN52ukPVGOSfB rGu3o0zu2g2PLsZEYZBh0a8C+eP7aAI6wES/+I4NBjHdY5PTZOo5nI5QNUYvQw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1603418554; a=rsa-sha256; cv=none; b=qwyF17x+SchAoe/0UqqKiPd+dpZSJ41nJTWC9DL+UEvJKzcjRoH/vs3sHugr+hrLYmO9Ke sEJm0sft5yrswRaSt7oXBK1u8qrPzOX1/QZAywkd4RY6AWCgJUCzc23ykvowzPamuRu72w mbV6FHpC8AxGbDCUGU2jqGo8LwwPy9h5178j4O+Cnktiev774g3zCr5ljrPKf0vl9BRPDe +fYtTUOiEZY9IHiPb5X8Fz2RC40tOYylEdY8YK4ZvtbS/0XhNqlKAyjn3jqvqHTcb5WdNZ WD/+Ua3u86b9e7OBX5GbBCjckooCZzsG8BShipjBikcJQy2HBC80cNJ2TF80NA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2020 02:02:34 -0000 After r366657 (currently, on r366953) I've tried to boot from a compression=zstd dataset but it failed to reach loader(8), see below. However, switching to CSM path (boot1.efi -> gptzfsboot) makes it work. Am I missing something? $ strings /boot/boot1.efi | fgrep zstd org.freebsd:zstd_compress $ strings /boot/gptzfsboot | fgrep zstd zstd /usr/src/sys/contrib/openzfs/module/zstd/zfs_zstd.c org.freebsd:zstd_compress $ zpool set bootfs=tank/ROOT/freebsd-zstd tank $ sh /usr/share/examples/bhyve/vmrun.sh -ATE -d /dev/nda0 -d /dev/nda1 host-freebsd Launching virtual machine "host-freebsd" ... fbuf frame buffer base: 0x827800000 [sz 16777216] >> FreeBSD EFI boot block Loader path: /boot/loader.efi Initializing modules: ZFS UFS Load Path: \EFI\BOOT\BOOTX64.EFI Load Device: PciRoot(0x0)/Pci(0x3,0x0)/Sata(0x0,0x0,0x0)/HD(2,GPT,,0x250,0x5B0) BootCurrent: 0000 BootOrder: 0000[*] 0001 0002 0003 Probing 8 block devices...not supported not supported not supported better not supported not supported not supported good done ZFS found the following pools: tank UFS found no partitions ZFS: unsupported compression algorithm (null) ZFS: i/o error - all block copies unavailable Failed to read node from tank (5) ZFS: unsupported compression algorithm (null) ZFS: i/o error - all block copies unavailable Failed to read node from tank (5) Failed to load '/boot/loader.efi' panic: No bootable partitions found! Boot Failed. EFI Hard Drive ... From owner-freebsd-current@freebsd.org Fri Oct 23 04:23:06 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 62F3F43C908 for ; Fri, 23 Oct 2020 04:23:06 +0000 (UTC) (envelope-from tsoome@me.com) Received: from pv50p00im-tydg10021701.me.com (pv50p00im-tydg10021701.me.com [17.58.6.54]) (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 4CHWLK4S8mz4rf6 for ; Fri, 23 Oct 2020 04:23:05 +0000 (UTC) (envelope-from tsoome@me.com) Received: from [192.168.150.140] (148-52-235-80.sta.estpak.ee [80.235.52.148]) by pv50p00im-tydg10021701.me.com (Postfix) with ESMTPSA id 46DEF84071B; Fri, 23 Oct 2020 04:23:03 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Toomas Soome Mime-Version: 1.0 (1.0) Subject: Re: uefi(8) fails to boot from ZFS with compression=zstd Date: Fri, 23 Oct 2020 07:23:01 +0300 Message-Id: <986E5318-5253-4CDD-ADEB-1DD009CCE759@me.com> References: Cc: freebsd-current@freebsd.org In-Reply-To: To: Jan Beich X-Mailer: iPhone Mail (18A8395) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.737 definitions=2020-10-23_01:2020-10-20, 2020-10-23 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-2006250000 definitions=main-2010230032 X-Rspamd-Queue-Id: 4CHWLK4S8mz4rf6 X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[me.com]; MV_CASE(0.50)[]; RWL_MAILSPIKE_GOOD(0.00)[17.58.6.54:from]; 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.25)[-0.253]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; 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(-0.95)[-0.953]; R_DKIM_ALLOW(-0.20)[me.com:s=1a1hai]; FREEFALL_USER(0.00)[tsoome]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.99)[-0.994]; MIME_GOOD(-0.10)[text/plain]; RECEIVED_SPAMHAUS_PBL(0.00)[80.235.52.148:received]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[17.58.6.54:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2020 04:23:06 -0000 Does it boot when you copy loader.efi to bootx64.efi? Toomas=20 > On 23. Oct 2020, at 05:02, Jan Beich wrote: >=20 > =EF=BB=BFAfter r366657 (currently, on r366953) I've tried to boot from a > compression=3Dzstd dataset but it failed to reach loader(8), see below. > However, switching to CSM path (boot1.efi -> gptzfsboot) makes it work. >=20 > Am I missing something? >=20 > $ strings /boot/boot1.efi | fgrep zstd > org.freebsd:zstd_compress >=20 > $ strings /boot/gptzfsboot | fgrep zstd > zstd > /usr/src/sys/contrib/openzfs/module/zstd/zfs_zstd.c > org.freebsd:zstd_compress >=20 > $ zpool set bootfs=3Dtank/ROOT/freebsd-zstd tank > $ sh /usr/share/examples/bhyve/vmrun.sh -ATE -d /dev/nda0 -d /dev/nda1 hos= t-freebsd > Launching virtual machine "host-freebsd" ... > fbuf frame buffer base: 0x827800000 [sz 16777216] >=20 >>> FreeBSD EFI boot block > Loader path: /boot/loader.efi >=20 > Initializing modules: ZFS UFS > Load Path: \EFI\BOOT\BOOTX64.EFI > Load Device: PciRoot(0x0)/Pci(0x3,0x0)/Sata(0x0,0x0,0x0)/HD(2,GPT,,0x250,0x5B0) > BootCurrent: 0000 > BootOrder: 0000[*] 0001 0002 0003 > Probing 8 block devices...not supported > not supported > not supported > better > not supported > not supported > not supported > good > done > ZFS found the following pools: tank > UFS found no partitions > ZFS: unsupported compression algorithm (null) > ZFS: i/o error - all block copies unavailable > Failed to read node from tank (5) > ZFS: unsupported compression algorithm (null) > ZFS: i/o error - all block copies unavailable > Failed to read node from tank (5) > Failed to load '/boot/loader.efi' > panic: No bootable partitions found! > Boot Failed. EFI Hard Drive > ... > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"= From owner-freebsd-current@freebsd.org Fri Oct 23 06:40:42 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6618643E5C1 for ; Fri, 23 Oct 2020 06:40:42 +0000 (UTC) (envelope-from jbeich@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 "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CHZP61xQCz3Ttv; Fri, 23 Oct 2020 06:40:42 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1354) id 3A09513BDE; Fri, 23 Oct 2020 06:40:42 +0000 (UTC) From: Jan Beich To: Toomas Soome Cc: freebsd-current@freebsd.org Subject: Re: uefi(8) fails to boot from ZFS with compression=zstd References: <986E5318-5253-4CDD-ADEB-1DD009CCE759@me.com> Date: Fri, 23 Oct 2020 08:40:38 +0200 Message-ID: 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=1603435242; h=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: references:references; bh=pDvIHvHnLim5eD5SRSZeOqBvOhjOrYVcQ8Dpkvav+8Q=; b=ICb0Pg+hVh9w0a1ZISBiy+OAdW8QzwlTeGdT5sSM8Oc1QEdUQmy9NDIhjzP8da1BQ08jId vqtkP57PaoWyEv4H6/Rp3NueyrkR5dlQC5dy9mhzD2WdGoLZPBdlRsjeewWayzR9T1JNB4 J8JLJX31nEV5L0xub6wvlV5p0JUWcWbdbGwFh9H4cDmck6R7aOC1tWmDJWJprVewbi4piI ZsAn9xCJ6U7ZFhrjRSzvljM8LzLwQByP+631HXbgvOS9ZKJ+KzasSEzANIrg6AEvjdH8GK h4x6ipbjvuLaLKL0G/+eBM5m90wseyMOJ2o8UewlcUNJLfxkJVjAL524osYTnA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1603435242; a=rsa-sha256; cv=none; b=l5cpDx7HAiv9NjtzD67k03WTeqyt3wo3RJdRJJOhQzTTfhAyJ3J5d8mjvTTcgnkTp6mT8C dB/4IdplJeDzVr0zxboePC0wHM3PJj+DXecLxmT7nqCvsyBjePNYrB6wnFQJRZLvFF8pMy YpstzejH2iKKUQg74sAhCQ64GZNU6JF85F0y06X0DAIjc+n2/F0kWbHt1C0/rhrTUyyn4V 4DpXdq//7GeI+Dx0diO0DoyOLm/vJZF7L1qZT2ChvvXYS7E4R43dS2UwnnPX27TCG8XhX2 9440SZuUdKx792ofy3i8y4/t2NsikB1P0OrN3pZR08psl4cLSZfH6n2ego6YHw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2020 06:40:42 -0000 Toomas Soome writes: > >> On 23. Oct 2020, at 05:02, Jan Beich wrote: >>=20 >> =EF=BB=BFAfter r366657 (currently, on r366953) I've tried to boot from a >> compression=3Dzstd dataset but it failed to reach loader(8), see below. >> However, switching to CSM path (boot1.efi -> gptzfsboot) makes it work. >>=20 >> Am I missing something? [...] > Does it boot when you copy loader.efi to bootx64.efi? Yes, skipping boot1.efi works fine. Luckily, my gptzfsboot + loader.efi still fit into 1Mb I've reserved for boot partitions. $ gpart show nda0 =3D> 40 1000215136 nda0 GPT (477G) 40 320 1 freebsd-boot (160K) 360 1688 2 efi (844K) 2048 1000213120 3 freebsd-zfs (477G) 1000215168 8 - free - (4.0K) $ sh /usr/share/examples/bhyve/vmrun.sh -ATE -d /dev/nda0 -d /dev/nda1 host= -freebsd Launching virtual machine "host-freebsd" ... fbuf frame buffer base: 0x827800000 [sz 16777216] Consoles: EFI console Reading loader env vars from /efi/freebsd/loader.env Setting currdev to disk0p2: FreeBSD/amd64 EFI loader, Revision 1.1 (Thu Oct 22 23:48:55 UTC 2020 foo@bar) Command line arguments: loader.efi Image base: 0x1e907000 EFI version: 2.40 EFI Firmware: BHYVE (rev 1.00) Console: efi (0x20001000) Load Path: \EFI\BOOT\BOOTX64.EFI Load Device: PciRoot(0x0)/Pci(0x3,0x0)/Sata(0x0,0x0,0x0)/HD(2,GPT,,0x168,0x698) BootCurrent: 0000 BootOrder: 0000[*] 0001 0002 0003 BootInfo Path: PciRoot(0x0)/Pci(0x3,0x0)/Sata(0x0,0x0,0x0) Ignoring Boot0000: Only one DP found Trying ESP: PciRoot(0x0)/Pci(0x3,0x0)/Sata(0x0,0x0,0x0)/HD(2,GPT,= ,0x168,0x698) Setting currdev to disk0p2: Trying: PciRoot(0x0)/Pci(0x3,0x0)/Sata(0x0,0x0,0x0)/HD(1,GPT,,0x2= 8,0x140) Setting currdev to disk0p1: Trying: PciRoot(0x0)/Pci(0x3,0x0)/Sata(0x0,0x0,0x0)/HD(3,GPT,,0x8= 00,0x3B9E0A80) Setting currdev to zfs:tank/ROOT/freebsd-zstd: Loading /boot/defaults/loader.conf Loading /boot/defaults/loader.conf Loading /boot/device.hints Loading /boot/loader.conf Loading /boot/loader.conf.local / - ______ ____ _____ _____ | ____| | _ \ / ____| __ \ | |___ _ __ ___ ___ | |_) | (___ | | | | | ___| '__/ _ \/ _ \| _ < \___ \| | | | | | | | | __/ __/| |_) |____) | |__| | | | | | | | || | | | |_| |_| \___|\___||____/|_____/|_____/ ``` = ` =E2=94=8C=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80Welcome to FreeBSD=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=90 s` `.....---.......--.``` -/ =E2=94=82 =E2=94=82 +o .--` = /y:` +. =E2=94=82 1. Boot Multi user [Enter] =E2=94=82 yo`:. = :o `+- =E2=94=82 2. Boot Single user =E2=94=82 y/ = -/` -o/ =E2=94=82 3. Escape to loader prompt =E2=94=82 .- = ::/sy+:. =E2=94=82 4. Reboot =E2=94=82 / = `-- / =E2=94=82 5. Cons: Dual (Serial primary) =E2=94=82 `: = :` =E2=94=82 =E2=94=82 `: = :` =E2=94=82 Options: =E2=94=82 / = / =E2=94=82 6. Kernel: default/kernel (1 of 2) =E2=94=82 .- = -. =E2=94=82 7. Boot Options =E2=94=82 -- = -. =E2=94=82 8. Boot Environments =E2=94=82 `:` = `:` =E2=94=82 =E2=94=82 .-- = `--. =E2=94=94=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94= =80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80= =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2= =94=80=E2=94=98 .---.....----. Loading kernel... /boot/kernel/kernel text=3D0x10c7c8 text=3D0x99a088 text=3D0x1a75e4 data=3D= 0x140 data=3D0x131aa4+0x4cd55c syms=3D[0x8+0x10f4d0+0x8+0x112349] Loading configured modules... /boot/firmware/intel-ucode.bin size=3D0x303800 /etc/hostid size=3D0x25 /boot/entropy size=3D0x1000 /boot/kernel/ichwd.ko size 0x8558 at 0x1b27000 Start @ 0xffffffff8030d000 ... EFI framebuffer information: addr, size 0xc1000000, 0x1000000 dimensions 1024 x 768 stride 1024 masks 0x00ff0000, 0x0000ff00, 0x000000ff, 0xff000000 From owner-freebsd-current@freebsd.org Fri Oct 23 16:32:29 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6AD6144A5CC; Fri, 23 Oct 2020 16:32:29 +0000 (UTC) (envelope-from melounmichal@gmail.com) Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CHqWw1K5Cz4LC2; Fri, 23 Oct 2020 16:32:28 +0000 (UTC) (envelope-from melounmichal@gmail.com) Received: by mail-wm1-x32b.google.com with SMTP id c16so2422422wmd.2; Fri, 23 Oct 2020 09:32:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:reply-to:subject:to:cc:references :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=LSOUjr7+2UhBbH5lMeRHhjAn/gqy5kvPoW84yNGTZAA=; b=oojZWDiTuSiA72HfTbyeQvfzdtKdWK/UGgFms7+c1cvRhBCSSnWdSRsTBqdg6h+inO J2Nm8hOxVnZN59Us7ys/O+BtEyMpRhpDEoLZBcRIxs6kDq1wvPFuuoAL3EO+mSPqVXdN 51VBt3n1J7Jxrara9eY16qq8knQ3yFz8RJGaIkTGVeQVKJcnIfMXJWpyGdLmqkYkS5K7 PCmhFIaDak1hQYI3wSJ8l8WgvKNAkY3uYj3eCuLGtBDcpj5nIW/AjncOfOju9ZCEh+tv GZHuTCT2mtVN9/X4+B7iH7RHvmckYVVNbPgO3ZfTwJSL6owkNKdH2/9JhGWR5AYJR6Ku D3Uw== X-Gm-Message-State: AOAM530t2ok5VYMNuo+9NUze7iEKo6dM0kK3iHyqFZw52FGJMeSbKjUa zUxvMVOGVxW7excNyb4UhDR8mpsRILY= X-Google-Smtp-Source: ABdhPJz2oGzdzc88aTvyy51uChxw46YxZAdpTt8eOt+SYv9OB/9wUlxfhZuHVZFleFXhFAcCdULuug== X-Received: by 2002:a7b:c114:: with SMTP id w20mr57783wmi.105.1603470746483; Fri, 23 Oct 2020 09:32:26 -0700 (PDT) Received: from [88.208.79.100] (halouny.humusoft.cz. [88.208.79.100]) by smtp.gmail.com with ESMTPSA id x1sm3961916wrl.41.2020.10.23.09.32.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 23 Oct 2020 09:32:25 -0700 (PDT) Sender: Michal Meloun From: Michal Meloun X-Google-Original-From: Michal Meloun Reply-To: mmel@freebsd.org Subject: Re: panic: non-current pmap 0xffffa00020eab8f0 on Rpi3 To: Mark Johnston Cc: bob prohaska , freebsd-current@freebsd.org, freebsd-arm@freebsd.org References: <20201006021029.GA13260@www.zefox.net> <20201006133743.GA96285@raichu> <20201019203954.GC46122@raichu> Message-ID: <454e1e9f-e839-8961-2ae1-9ddd86f1cefd@freebsd.org> Date: Fri, 23 Oct 2020 18:32:25 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 MIME-Version: 1.0 In-Reply-To: <20201019203954.GC46122@raichu> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4CHqWw1K5Cz4LC2 X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.43 / 15.00]; HAS_REPLYTO(0.00)[mmel@freebsd.org]; 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(-0.46)[-0.459]; 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(-0.99)[-0.994]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-0.98)[-0.976]; MIME_GOOD(-0.10)[text/plain]; REPLYTO_DOM_NEQ_FROM_DOM(0.00)[]; MID_RHS_MATCH_TO(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::32b:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-arm,freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Oct 2020 16:32:29 -0000 On 19.10.2020 22:39, Mark Johnston wrote: > On Fri, Oct 16, 2020 at 11:53:56AM +0200, Michal Meloun wrote: >> >> >> On 06.10.2020 15:37, Mark Johnston wrote: >>> On Mon, Oct 05, 2020 at 07:10:29PM -0700, bob prohaska wrote: >>>> Still seeing non-current pmap panics on the Pi3, this time a B+ running >>>> 13.0-CURRENT (GENERIC-MMCCAM) #0 71e02448ffb-c271826(master) >>>> during a -j4 buildworld. The backtrace reports >>>> >>>> panic: non-current pmap 0xffffa00020eab8f0 >>> >>> Could you show the output of "show procvm" from the debugger? >> >> I see same panic too, in my case its very rare - typical scenario is >> rebuild of kf5 ports (~250, 2 days of full load). Any idea how to debug >> this? >> Michal > > I suspect that there is some race involving the pmap switching in > vmspace_exit(), but I can't see it. In the example below, presumably > process 22604 on CPU 0 is also exiting? Could you show the backtrace?> > It would also be useful to see the value of PCPU_GET(curpmap) at the > time of the panic. I'm not sure if there's a way to get that from DDB, > but I suspect it should be equal to &vmspace0->vm_pmap. Mark, I think that I found problem. The PCPU_GET() is not (and is not supposed to be) an atomic operation, it expects that thread is at least pinned. This is not true for pmap_remove_pages() - so I think that the KASSERT is racy and shoud be removed (or at least covered by sched_pin()/sched_unpin() pair). What do you think? > > I think vmspace_exit() should issue a release fence with the cmpset and > an acquire fence when handling the refcnt == 1 case, Yep, true, fully agree. Michal but I don't see why > that would make a difference here. So, if you can test a debug patch, > this one will yield a bit more debug info. If you can provide access to > a vmcore and kernel debug symbols, that'd be even better. > > diff --git a/sys/arm64/arm64/pmap.c b/sys/arm64/arm64/pmap.c > index 284f00b3cc0d..3c53ae3b4c1e 100644 > --- a/sys/arm64/arm64/pmap.c > +++ b/sys/arm64/arm64/pmap.c > @@ -4838,7 +4838,8 @@ pmap_remove_pages(pmap_t pmap) > int allfree, field, freed, idx, lvl; > vm_paddr_t pa; > > - KASSERT(pmap == PCPU_GET(curpmap), ("non-current pmap %p", pmap)); > + KASSERT(pmap == PCPU_GET(curpmap), > + ("non-current pmap %p %p", pmap, PCPU_GET(curpmap))); > > lock = NULL; > > diff --git a/sys/vm/vm_map.c b/sys/vm/vm_map.c > index c20005ae64cf..0ad415e3b88c 100644 > --- a/sys/vm/vm_map.c > +++ b/sys/vm/vm_map.c > @@ -358,7 +358,10 @@ vmspace_exit(struct thread *td) > p = td->td_proc; > vm = p->p_vmspace; > atomic_add_int(&vmspace0.vm_refcnt, 1); > - refcnt = vm->vm_refcnt; > + refcnt = atomic_load_int(&vm->vm_refcnt); > + > + KASSERT(vmspace_pmap(vm) == PCPU_GET(curpmap), > + ("non-current pmap %p %p", pmap, PCPU_GET(curpmap))); > do { > if (refcnt > 1 && p->p_vmspace != &vmspace0) { > /* Switch now since other proc might free vmspace */ > From owner-freebsd-current@freebsd.org Sat Oct 24 06:33:47 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 83C1E43D867; Sat, 24 Oct 2020 06:33:47 +0000 (UTC) (envelope-from samy.mahmoudi@gmail.com) Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0: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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CJBBf1MrXz46rC; Sat, 24 Oct 2020 06:33:45 +0000 (UTC) (envelope-from samy.mahmoudi@gmail.com) Received: by mail-pl1-x62a.google.com with SMTP id w11so2145393pll.8; Fri, 23 Oct 2020 23:33:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7Tg/XapAchla0ZwjUEx5MJfCbOnN6YZlYPppfyEf4/Q=; b=Ek5LhGW3SVotf3kmgRfJm6O+ZYiYtuqzL6mKFjAeLAmckACWngjg04QO71bozmyx9Z x2bnTC3zO4nFbWtOqtoxalk5IZYU0+3U5xUulaErCiNunR0m0fV25IfVum0j7m5Sv5JI zz54KOtL/DYBKMvmmQ/j3VqZem35OZO30uzBovJDX0Xeco2SXAR/l63nZjkZhNJt6q31 HWhXdVE0gFfNPKGsxh2VrSzhAGaQ42OcEq0CmBvvM1+jOJXcQyY7G8fwpv9jNv/53n8R kf2ZOnwWYMBGISsQadZ48DfnA1LRPTTpJINualEAYjSQTX7j/89zv6k6DwfZS7UzDG24 i9lw== X-Gm-Message-State: AOAM532P9rJR9lN68VUMikFII2jFM2hmro/ZVyHeQoC92olUvoMfkC+8 x5dSrBgvu+Qaoqr99H42q4TiQHXe2kvYPJe9WP0= X-Google-Smtp-Source: ABdhPJxw60LsekPfivJDcxqMGu5EacT8BQR9J9ElCWj/wXhyHN62OAbPIXxnZUOlxpCGLdI2KxxNN2/1/YsyoMilpf4= X-Received: by 2002:a17:902:780f:b029:d6:3413:9fe8 with SMTP id p15-20020a170902780fb02900d634139fe8mr469363pll.46.1603521224462; Fri, 23 Oct 2020 23:33:44 -0700 (PDT) MIME-Version: 1.0 References: <33381216-498a-51ff-839c-da772c43b60e@FreeBSD.org> <20201022203752.36fb6f3f@laptop.domain> <2E4B5AFC-C23E-4F33-8EFA-D285A998A4F0@me.com> <20201022233451.40a3aed6@laptop.domain> In-Reply-To: <20201022233451.40a3aed6@laptop.domain> From: Samy Mahmoudi Date: Sat, 24 Oct 2020 02:33:33 -0400 Message-ID: Subject: Re: Zpool doesn't boot anymore after FreeBSD 12.1 To: "Sergey V. Dyatko" Cc: Toomas Soome , FreeBSD Current , freebsd-stable@freebsd.org X-Rspamd-Queue-Id: 4CJBBf1MrXz46rC X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.16 / 15.00]; MAILMAN_DEST(0.00)[freebsd-current,freebsd-stable]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.68)[-0.684]; 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]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.001]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; NEURAL_HAM_LONG(-0.97)[-0.975]; 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::62a:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; SUSPICIOUS_RECIPS(1.50)[]; FREEMAIL_CC(0.00)[me.com,freebsd.org] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Oct 2020 06:33:47 -0000 Hi! > That's why I have terribly outdated 13-CURRENT on a bunch of servers and can't update them. The way you're holding your head on your avatar looks like you upgraded your servers' pools and now realize your mistake! Fortunately, you did not ;-) From owner-freebsd-current@freebsd.org Sat Oct 24 19:37:42 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id F3744452917; Sat, 24 Oct 2020 19:37:42 +0000 (UTC) (envelope-from markjdb@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 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CJWbB1dPfz417P; Sat, 24 Oct 2020 19:37:41 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qk1-x731.google.com with SMTP id b69so4835244qkg.8; Sat, 24 Oct 2020 12:37:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=e85WFxtcM8vw1yb7YkMm1o5VYF29zO92gdczz6GqUVo=; b=TMEieT6QqIoF4ZeSrCIsSuxmShA6YTTpSZqr7hfv/QPipYcnQ5+KmdU388SaCja7WL qX/NdrLxRHWIN2kcMnS4b5YI6gferBFvQngRThLRXwP8TrQL9zngB4wINzlYfr9QYasO zDFSnkgOUwtuZIhEdafQCF8rzXnEldDbHnOFS5te+eSpe2PVB3+wtmo3gAi1C1dTkzTw x0snomkTZU9ZsGzHn1TANxTA+9+74yM7lM1fu+f7iiIRqD8kGF2Zd3tnAYGfNyTmZ+G5 A8x4v1h13N7S30sUrDFGsZn7f8VVyUWIRGkeg93Pp6nKUpV90u7sfbkS8fWPN01r0fdI rAYA== X-Gm-Message-State: AOAM533VpC6exYKdWFGvcRNpVGhdy7WGRD0g5xambk1vAq3GP/YppB/9 PkBx+B6RgSCSLIzDZnc6qBlQMl7uZs8= X-Google-Smtp-Source: ABdhPJw8yryx1PcxuEZ0tBIni/FP8pKTPzv24Z5nk9VgnRnMtizA6lETmKy8ca9JwwYHiOz/o0ScHA== X-Received: by 2002:a05:620a:142d:: with SMTP id k13mr8389579qkj.315.1603568260845; Sat, 24 Oct 2020 12:37:40 -0700 (PDT) Received: from raichu (toroon0560w-lp130-01-174-88-77-103.dsl.bell.ca. [174.88.77.103]) by smtp.gmail.com with ESMTPSA id f3sm3349914qkl.134.2020.10.24.12.37.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 24 Oct 2020 12:37:39 -0700 (PDT) Sender: Mark Johnston Date: Sat, 24 Oct 2020 15:37:35 -0400 From: Mark Johnston To: mmel@freebsd.org Cc: bob prohaska , freebsd-current@freebsd.org, freebsd-arm@freebsd.org Subject: Re: panic: non-current pmap 0xffffa00020eab8f0 on Rpi3 Message-ID: <20201024193735.GA7755@raichu> References: <20201006021029.GA13260@www.zefox.net> <20201006133743.GA96285@raichu> <20201019203954.GC46122@raichu> <454e1e9f-e839-8961-2ae1-9ddd86f1cefd@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <454e1e9f-e839-8961-2ae1-9ddd86f1cefd@freebsd.org> X-Rspamd-Queue-Id: 4CJWbB1dPfz417P X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.01 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[text/plain]; MID_RHS_NOT_FQDN(0.50)[]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-0.97)[-0.974]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; NEURAL_HAM_SHORT(-0.28)[-0.284]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::731:from]; NEURAL_HAM_MEDIUM(-1.05)[-1.053]; 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]; MAILMAN_DEST(0.00)[freebsd-current,freebsd-arm] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Oct 2020 19:37:43 -0000 On Fri, Oct 23, 2020 at 06:32:25PM +0200, Michal Meloun wrote: > > > On 19.10.2020 22:39, Mark Johnston wrote: > > On Fri, Oct 16, 2020 at 11:53:56AM +0200, Michal Meloun wrote: > >> > >> > >> On 06.10.2020 15:37, Mark Johnston wrote: > >>> On Mon, Oct 05, 2020 at 07:10:29PM -0700, bob prohaska wrote: > >>>> Still seeing non-current pmap panics on the Pi3, this time a B+ running > >>>> 13.0-CURRENT (GENERIC-MMCCAM) #0 71e02448ffb-c271826(master) > >>>> during a -j4 buildworld. The backtrace reports > >>>> > >>>> panic: non-current pmap 0xffffa00020eab8f0 > >>> > >>> Could you show the output of "show procvm" from the debugger? > >> > >> I see same panic too, in my case its very rare - typical scenario is > >> rebuild of kf5 ports (~250, 2 days of full load). Any idea how to debug > >> this? > >> Michal > > > > I suspect that there is some race involving the pmap switching in > > vmspace_exit(), but I can't see it. In the example below, presumably > > process 22604 on CPU 0 is also exiting? Could you show the backtrace?> > > It would also be useful to see the value of PCPU_GET(curpmap) at the > > time of the panic. I'm not sure if there's a way to get that from DDB, > > but I suspect it should be equal to &vmspace0->vm_pmap. > Mark, > I think that I found problem. > The PCPU_GET() is not (and is not supposed to be) an atomic operation, > it expects that thread is at least pinned. > This is not true for pmap_remove_pages() - so I think that the KASSERT > is racy and shoud be removed (or at least covered by > sched_pin()/sched_unpin() pair). > What do you think? I think you're right. On amd64 curpmap is loaded using a single instruction so the assertion happens to work properly. On arm64 we have: 0xffff0000007ff138 <+32>: mov x8, x18 0xffff0000007ff13c <+36>: ldr x8, [x8, #216] 0xffff0000007ff140 <+40>: mov x26, x0 0xffff0000007ff144 <+44>: cmp x8, x0 Though, it looks like arm64's PCPU_GET could be modified to combine the first two instructions. To fix it, we could perhaps change the KASSERT to verify that pmap == vmspace_pmap(curthread->td_proc->p_vmspace). The various implementations of pmap_remove_pages() have different flavours of the same check and it would be nice to unify them. Using sched_pin() would also be fine I think. > > I think vmspace_exit() should issue a release fence with the cmpset and > > an acquire fence when handling the refcnt == 1 case, > Yep, true, fully agree. Alan pointed out in the review that pmap_remove_pages() acquires the pmap lock, which I missed, so I don't think the extra barriers are necessary after all.