From owner-freebsd-current@freebsd.org Sun Dec 27 22:30: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 9AC8B4C907A for ; Sun, 27 Dec 2020 22:30:55 +0000 (UTC) (envelope-from me+freebsd@igalic.co) Received: from mail2.protonmail.ch (mail2.protonmail.ch [185.70.40.22]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "protonmail.com", Issuer "SwissSign Server Gold CA 2014 - G22" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D3wPT4SXtz3pWv for ; Sun, 27 Dec 2020 22:30:53 +0000 (UTC) (envelope-from me+freebsd@igalic.co) Date: Sun, 27 Dec 2020 22:30:36 +0000 To: "freebsd-current@freebsd.org" , "freebsd-pkgbase@freebsd.org" From: =?utf-8?Q?Mina_Gali=C4=87?= Reply-To: =?utf-8?Q?Mina_Gali=C4=87?= Subject: Unofficial PkgBase Repository Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=1.8 required=10.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NEW_DOMAIN_28D, URIBL_FRESH_28D_SURBL shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mailout.protonmail.ch X-Rspamd-Queue-Id: 4D3wPT4SXtz3pWv X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.50 / 15.00]; HAS_REPLYTO(0.00)[me+freebsd@igalic.co]; RWL_MAILSPIKE_VERYGOOD(0.00)[185.70.40.22:from]; R_DKIM_ALLOW(-0.20)[igalic.co:s=protonmail2]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[me]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24]; ARC_NA(0.00)[]; DMARC_NA(0.00)[igalic.co]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[igalic.co:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-1.000]; TO_DN_EQ_ADDR_ALL(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; R_MIXED_CHARSET(1.00)[subject]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH]; TAGGED_FROM(0.00)[freebsd]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 27 Dec 2020 22:30:55 -0000 Hi folks, Recently I've been working on on building a PkgBase repository The repository is in good enough shape now that I believe it can be announc= ed publicly! https://alpha.pkgbase.live/ is built with poudriere and serves -CURRENT packages for AMD64 and AARCH64. The host itself is still updated with https://up.bsd.lv/ but the jail servi= ng the packages is built and updated with PkgBase. It's hosted on a vServer at Hetzner in Helsinki There's still a number of things to do before I'd consider the repository p= roduction quality, hence the domain name. Two of the most important ones are: - Package Signing: https://reviews.freebsd.org/D27690 - HTTP Caching of packages: https://github.com/freebsd/poudriere/pull/751 I will add more more architectures when I hear your feedback on what you wo= uld like to see. It would also be nice to add "production" builds `WITHOUT_LLVM_ASSERTIONS` = and `WITH_MALLOC_PRODUCTION`. it just feels=E2=80=A6 wrong until 13 STABLE is branched =F0=9F=98=85 Happy testing! Looking forward to your feedback. p.s.: if it feels slow, blame virtio + vnet Best regards, Mina Gali=C4=87 Web: https://igalic.co/ From owner-freebsd-current@freebsd.org Mon Dec 28 12:08:31 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 94F064B20CB for ; Mon, 28 Dec 2020 12:08:31 +0000 (UTC) (envelope-from garga.bsd@gmail.com) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D4GXt6SZFz3L9p for ; Mon, 28 Dec 2020 12:08:30 +0000 (UTC) (envelope-from garga.bsd@gmail.com) Received: by mail-qk1-x733.google.com with SMTP id f26so8635193qka.0 for ; Mon, 28 Dec 2020 04:08:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=WWMowXHwDis1yajkKnKkDlXadU/Xmruj3SVlqVJLlFo=; b=g6ovhYUZEGZN5ERDF1fa84SEHYhlTAdzoRBfdvZU4PJFkYIyb0l3hokWUOUFuOI8Xl xiWmizT3iREWb0ec2lWLmrCzUP61UAeYk/J4DG5rAO5CSgaVqBVF0Di+WD+iJNgwJhPt Cx5UguQBGnFTsY7dvSj4/MGdGMQEjYdBMy0P02UvHX1tRT9F3nVhlW+G+KBkyzGVI7iq YIdxuYT6FER19BOyjG6Nlc2KpzWfRASijHD0sh88yL2AYMGDv9QcZxQeQwgMvXl2w8Z+ qIByK9SdAnTclIwCFQq2meQi3t9EXyPMRWBeuKMvIHT3OKvvwk3OXgCDewoGye8VVwpl 4uLw== X-Gm-Message-State: AOAM533k6PAf/6S+jMghv094ui91qOgZG3VaJT1sHi0dmxROqM6voBB8 xxQnepsKliq74xJpGStNvNkTSBQTNTzYdw== X-Google-Smtp-Source: ABdhPJwKmCtWZgzd8ZSTP99CsmvDJNEt8MRS4VY1jImCOkUFGjen0pS0F2+qh5q8HnnogyGo8cQRMg== X-Received: by 2002:ae9:ed41:: with SMTP id c62mr43351562qkg.111.1609157309720; Mon, 28 Dec 2020 04:08:29 -0800 (PST) Received: from mbp.home (200-12-5-188.rev.tribenet.com.br. [200.12.5.188]) by smtp.gmail.com with ESMTPSA id u19sm5647215qkm.90.2020.12.28.04.08.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 28 Dec 2020 04:08:28 -0800 (PST) Sender: Renato Botelho Subject: Re: git and the loss of revision numbers To: Michael Grimm , FreeBSD Current References: <54116640-E6A1-4C53-9D7E-4384F942628E@ellael.org> <8ABAC674-89AA-47BE-996C-4DF6E7713F21@ellael.org> From: Renato Botelho Message-ID: <53dd689b-2401-8e90-f332-50c60c549c2e@FreeBSD.org> Date: Mon, 28 Dec 2020 09:08:25 -0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <8ABAC674-89AA-47BE-996C-4DF6E7713F21@ellael.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4D4GXt6SZFz3L9p X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.20 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FORGED_SENDER(0.30)[garga@FreeBSD.org,gargabsd@gmail.com]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[2607:f8b0:4864:20::733:from]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; TAGGED_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[garga@FreeBSD.org,gargabsd@gmail.com]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[FreeBSD.org]; SPAMHAUS_ZRD(0.00)[2607:f8b0:4864:20::733:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::733:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 28 Dec 2020 12:08:31 -0000 On 24/12/20 11:15, Michael Grimm wrote: > Correction: > >> On 24. Dec 2020, at 15:11, Michael Grimm wrote: >> >> In the past I could easily judge if there was a need to buildworld or buildkernel: If uname shows a larger revision number than those in advisories or notices. > > In the past I could easily judge if there was a need to buildworld or buildkernel: If uname shows a smaller revision number than those in advisories or notices. FreeBSD bast.garga.net.br 13.0-CURRENT FreeBSD 13.0-CURRENT #19 3cc0c0d66a0-c255241(main)-dirty: ^ This is an incremental counter of commits -- Renato Botelho From owner-freebsd-current@freebsd.org Mon Dec 28 16:27:39 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 E5D3B4BA680 for ; Mon, 28 Dec 2020 16:27:39 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-io1-f43.google.com (mail-io1-f43.google.com [209.85.166.43]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D4NHt6YhPz3vp2; Mon, 28 Dec 2020 16:27:38 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: by mail-io1-f43.google.com with SMTP id y5so9816616iow.5; Mon, 28 Dec 2020 08:27:38 -0800 (PST) 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=HhhfPItkC1LhmM9vC+k55Q1Y1UfEwf9tn7GcMTB+DlE=; b=ddwTeFZfPakq0MRNwP2JcT46G3WTAfxIaPJBFBJHmQURP6Fe+Uei8PzL17hC1/Pima LZ0bdIZjb9lnymmRSqLWqnzayO+zPbpjuVqGcM/TF//sx/DmB7KIEhHIKzGykAh6W32j Fi8VDOF74rI/G9z8UjI8lQhI+rczBQN8Uc19hChHNDfVrZnv3IcEM8vWTk1EkJYn3djv 4DNqgJE8SSx1ecgqSiec6D/K4hGX2jAbeA0c8KtBM594GFJLZ0ckcf2X8IvRtA3iDoMK 80tu1s8b69saurpjcRlb4GG7cxCX374bUvAc7eue0Za1Nzf6/TkCWcYN3wEFXZWuJbuz dlvg== X-Gm-Message-State: AOAM532sNSiOA/opfH5vT3JlhdTIKSqxu4FFJjMqgIOcKImZ87itcoTW iYthhkYkpLLYC5MUyGygDBTs0CAJ9LZHhVlXoUEPviN7VW8uKUKy X-Google-Smtp-Source: ABdhPJySVDgfSolHI9Okfy6d9RyYlaW5Bl6YV6vk8bs2dSZ/bC5MyzLygQSaHmglelrLVggpZlXpMcow/1a25lYSznY= X-Received: by 2002:a6b:1451:: with SMTP id 78mr37347372iou.102.1609172857051; Mon, 28 Dec 2020 08:27:37 -0800 (PST) MIME-Version: 1.0 References: <54116640-E6A1-4C53-9D7E-4384F942628E@ellael.org> <8ABAC674-89AA-47BE-996C-4DF6E7713F21@ellael.org> <53dd689b-2401-8e90-f332-50c60c549c2e@FreeBSD.org> In-Reply-To: <53dd689b-2401-8e90-f332-50c60c549c2e@FreeBSD.org> From: Ed Maste Date: Mon, 28 Dec 2020 11:27:24 -0500 Message-ID: Subject: Re: git and the loss of revision numbers To: Renato Botelho Cc: Michael Grimm , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4D4NHt6YhPz3vp2 X-Spamd-Bar: - X-Spamd-Result: default: False [-1.99 / 15.00]; ARC_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FREEFALL_USER(0.00)[carpeddiem]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; RCVD_TLS_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; RBL_DBL_DONT_QUERY_IPS(0.00)[209.85.166.43:from]; NEURAL_SPAM_SHORT(0.01)[0.015]; SPAMHAUS_ZRD(0.00)[209.85.166.43:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_IN_DNSWL_NONE(0.00)[209.85.166.43:from]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.166.43:from]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; MAILMAN_DEST(0.00)[freebsd-current]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 28 Dec 2020 16:27:40 -0000 On Mon, 28 Dec 2020 at 07:08, Renato Botelho wrote: > > FreeBSD bast.garga.net.br 13.0-CURRENT FreeBSD 13.0-CURRENT #19 > 3cc0c0d66a0-c255241(main)-dirty: > ^ > This is an incremental counter of commits Also, uqs@ recently fixed an issue in newvers.sh (including the final, non-updating svn revision) and reordered the information. An example of the new format: main-c255126-gb81783dc98e6-dirty \ \ \ \ \ \ \ local modifications \ \ hash \ commit count branch From owner-freebsd-current@freebsd.org Mon Dec 28 20:24: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 AABEA4C0186 for ; Mon, 28 Dec 2020 20:24:47 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D4TYW4FL2z4fsK; Mon, 28 Dec 2020 20:24:47 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro.local (unknown [IPv6:2601:648:8681:1cb0:6d19:4439:be3e:85c7]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 2957D217C2; Mon, 28 Dec 2020 20:24:47 +0000 (UTC) (envelope-from jhb@FreeBSD.org) To: Mateusz Guzik , Konstantin Belousov Cc: "freebsd-current@freebsd.org" From: John Baldwin Subject: panic: Assertion pgrp->pg_jobc > 0 failed at kern_proc.c:816 Autocrypt: addr=jhb@FreeBSD.org; keydata= mQGiBETQ+XcRBADMFybiq69u+fJRy/0wzqTNS8jFfWaBTs5/OfcV7wWezVmf9sgwn8TW0Dk0 c9MBl0pz+H01dA2ZSGZ5fXlmFIsee1WEzqeJzpiwd/pejPgSzXB9ijbLHZ2/E0jhGBcVy5Yo /Tw5+U/+laeYKu2xb0XPvM0zMNls1ah5OnP9a6Ql6wCgupaoMySb7DXm2LHD1Z9jTsHcAQMD /1jzh2BoHriy/Q2s4KzzjVp/mQO5DSm2z14BvbQRcXU48oAosHA1u3Wrov6LfPY+0U1tG47X 1BGfnQH+rNAaH0livoSBQ0IPI/8WfIW7ub4qV6HYwWKVqkDkqwcpmGNDbz3gfaDht6nsie5Z pcuCcul4M9CW7Md6zzyvktjnbz61BADGDCopfZC4of0Z3Ka0u8Wik6UJOuqShBt1WcFS8ya1 oB4rc4tXfSHyMF63aPUBMxHR5DXeH+EO2edoSwViDMqWk1jTnYza51rbGY+pebLQOVOxAY7k do5Ordl3wklBPMVEPWoZ61SdbcjhHVwaC5zfiskcxj5wwXd2E9qYlBqRg7QeSm9obiBCYWxk d2luIDxqaGJARnJlZUJTRC5vcmc+iGAEExECACAFAkTQ+awCGwMGCwkIBwMCBBUCCAMEFgID AQIeAQIXgAAKCRBy3lIGd+N/BI6RAJ9S97fvbME+3hxzE3JUyUZ6vTewDACdE1stFuSfqMvM jomvZdYxIYyTUpC5Ag0ERND5ghAIAPwsO0B7BL+bz8sLlLoQktGxXwXQfS5cInvL17Dsgnr3 1AKa94j9EnXQyPEj7u0d+LmEe6CGEGDh1OcGFTMVrof2ZzkSy4+FkZwMKJpTiqeaShMh+Goj XlwIMDxyADYvBIg3eN5YdFKaPQpfgSqhT+7El7w+wSZZD8pPQuLAnie5iz9C8iKy4/cMSOrH YUK/tO+Nhw8Jjlw94Ik0T80iEhI2t+XBVjwdfjbq3HrJ0ehqdBwukyeJRYKmbn298KOFQVHO EVbHA4rF/37jzaMadK43FgJ0SAhPPF5l4l89z5oPu0b/+5e2inA3b8J3iGZxywjM+Csq1tqz hltEc7Q+E08AAwUIAL+15XH8bPbjNJdVyg2CMl10JNW2wWg2Q6qdljeaRqeR6zFus7EZTwtX sNzs5bP8y51PSUDJbeiy2RNCNKWFMndM22TZnk3GNG45nQd4OwYK0RZVrikalmJY5Q6m7Z16 4yrZgIXFdKj2t8F+x613/SJW1lIr9/bDp4U9tw0V1g3l2dFtD3p3ZrQ3hpoDtoK70ioIAjjH aIXIAcm3FGZFXy503DOA0KaTWwvOVdYCFLm3zWuSOmrX/GsEc7ovasOWwjPn878qVjbUKWwx Q4QkF4OhUV9zPtf9tDSAZ3x7QSwoKbCoRCZ/xbyTUPyQ1VvNy/mYrBcYlzHodsaqUDjHuW+I SQQYEQIACQUCRND5ggIbDAAKCRBy3lIGd+N/BCO8AJ9j1dWVQWxw/YdTbEyrRKOY8YZNwwCf afMAg8QvmOWnHx3wl8WslCaXaE8= Message-ID: <8f88c925-f12a-6a51-c2b3-c21c55de8dab@FreeBSD.org> Date: Mon, 28 Dec 2020 12:24:44 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 28 Dec 2020 20:24:47 -0000 I got this panic again today in a VM when quitting a gdb session after killing a child process via 'kill'. panic: Assertion pgrp->pg_jobc > 0 failed at /git/bhyve/sys/kern/kern_proc.c:816 cpuid = 1 time = 1609185862 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00946547f0 vpanic() at vpanic+0x181/frame 0xfffffe0094654840 panic() at panic+0x43/frame 0xfffffe00946548a0 _refcount_update_saturated() at _refcount_update_saturated/frame 0xfffffe00946548e0 killjobc() at killjobc+0x6a6/frame 0xfffffe0094654940 exit1() at exit1+0x6af/frame 0xfffffe00946549b0 sys_sys_exit() at sys_sys_exit+0xd/frame 0xfffffe00946549c0 amd64_syscall() at amd64_syscall+0x12e/frame 0xfffffe0094654af0 fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe0094654af0 --- syscall (1, FreeBSD ELF64, sys_sys_exit), rip = 0x8024c8f0a, rsp = 0x7fffffffe358, rbp = 0x7fffffffe370 --- KDB: enter: panic [ thread pid 44034 tid 102484 ] Stopped at kdb_enter+0x37: movq $0,0x10ab066(%rip) >From what I can tell, the child process that was killed via 'kill' has not yet exited and is stuck in ptracestop() from fork(): (kgdb) where #0 sched_switch (td=0xfffffe0094001a00, flags=) at /git/bhyve/sys/kern/sched_ule.c:2147 #1 0xffffffff80bf4015 in mi_switch (flags=266) at /git/bhyve/sys/kern/kern_synch.c:542 #2 0xffffffff80bfeba5 in thread_suspend_switch (td=, p=) at /git/bhyve/sys/kern/kern_thread.c:1477 #3 0xffffffff80bef04b in ptracestop (td=0xfffffe0094001a00, sig=17, si=0x0) at /git/bhyve/sys/kern/kern_sig.c:2642 #4 0xffffffff80ba1a54 in fork_return (td=0xfffffe0094001a00, frame=0xfffffe0094671b00) at /git/bhyve/sys/kern/kern_fork.c:1106 #5 0xffffffff80ba18b0 in fork_exit (callout=0xffffffff80ba1950 , arg=0xfffffe0094001a00, frame=0xfffffe0094671b00) at /git/bhyve/sys/kern/kern_fork.c:1069 #6 #7 0x00000008007b71aa in ?? () kgdb can't find the panicking process due to the zombproc removal, so I will have to go work on kgdb to recover from that change. :( -- John Baldwin From owner-freebsd-current@freebsd.org Mon Dec 28 20:44:21 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 68F5B4C1024 for ; Mon, 28 Dec 2020 20:44:21 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D4V052KdGz4hyk; Mon, 28 Dec 2020 20:44:21 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro.local (unknown [IPv6:2601:648:8681:1cb0:6d19:4439:be3e:85c7]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id B345B21BD0; Mon, 28 Dec 2020 20:44:20 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Subject: Re: panic: Assertion pgrp->pg_jobc > 0 failed at kern_proc.c:816 From: John Baldwin To: Mateusz Guzik , Konstantin Belousov Cc: "freebsd-current@freebsd.org" References: <8f88c925-f12a-6a51-c2b3-c21c55de8dab@FreeBSD.org> Autocrypt: addr=jhb@FreeBSD.org; keydata= mQGiBETQ+XcRBADMFybiq69u+fJRy/0wzqTNS8jFfWaBTs5/OfcV7wWezVmf9sgwn8TW0Dk0 c9MBl0pz+H01dA2ZSGZ5fXlmFIsee1WEzqeJzpiwd/pejPgSzXB9ijbLHZ2/E0jhGBcVy5Yo /Tw5+U/+laeYKu2xb0XPvM0zMNls1ah5OnP9a6Ql6wCgupaoMySb7DXm2LHD1Z9jTsHcAQMD /1jzh2BoHriy/Q2s4KzzjVp/mQO5DSm2z14BvbQRcXU48oAosHA1u3Wrov6LfPY+0U1tG47X 1BGfnQH+rNAaH0livoSBQ0IPI/8WfIW7ub4qV6HYwWKVqkDkqwcpmGNDbz3gfaDht6nsie5Z pcuCcul4M9CW7Md6zzyvktjnbz61BADGDCopfZC4of0Z3Ka0u8Wik6UJOuqShBt1WcFS8ya1 oB4rc4tXfSHyMF63aPUBMxHR5DXeH+EO2edoSwViDMqWk1jTnYza51rbGY+pebLQOVOxAY7k do5Ordl3wklBPMVEPWoZ61SdbcjhHVwaC5zfiskcxj5wwXd2E9qYlBqRg7QeSm9obiBCYWxk d2luIDxqaGJARnJlZUJTRC5vcmc+iGAEExECACAFAkTQ+awCGwMGCwkIBwMCBBUCCAMEFgID AQIeAQIXgAAKCRBy3lIGd+N/BI6RAJ9S97fvbME+3hxzE3JUyUZ6vTewDACdE1stFuSfqMvM jomvZdYxIYyTUpC5Ag0ERND5ghAIAPwsO0B7BL+bz8sLlLoQktGxXwXQfS5cInvL17Dsgnr3 1AKa94j9EnXQyPEj7u0d+LmEe6CGEGDh1OcGFTMVrof2ZzkSy4+FkZwMKJpTiqeaShMh+Goj XlwIMDxyADYvBIg3eN5YdFKaPQpfgSqhT+7El7w+wSZZD8pPQuLAnie5iz9C8iKy4/cMSOrH YUK/tO+Nhw8Jjlw94Ik0T80iEhI2t+XBVjwdfjbq3HrJ0ehqdBwukyeJRYKmbn298KOFQVHO EVbHA4rF/37jzaMadK43FgJ0SAhPPF5l4l89z5oPu0b/+5e2inA3b8J3iGZxywjM+Csq1tqz hltEc7Q+E08AAwUIAL+15XH8bPbjNJdVyg2CMl10JNW2wWg2Q6qdljeaRqeR6zFus7EZTwtX sNzs5bP8y51PSUDJbeiy2RNCNKWFMndM22TZnk3GNG45nQd4OwYK0RZVrikalmJY5Q6m7Z16 4yrZgIXFdKj2t8F+x613/SJW1lIr9/bDp4U9tw0V1g3l2dFtD3p3ZrQ3hpoDtoK70ioIAjjH aIXIAcm3FGZFXy503DOA0KaTWwvOVdYCFLm3zWuSOmrX/GsEc7ovasOWwjPn878qVjbUKWwx Q4QkF4OhUV9zPtf9tDSAZ3x7QSwoKbCoRCZ/xbyTUPyQ1VvNy/mYrBcYlzHodsaqUDjHuW+I SQQYEQIACQUCRND5ggIbDAAKCRBy3lIGd+N/BCO8AJ9j1dWVQWxw/YdTbEyrRKOY8YZNwwCf afMAg8QvmOWnHx3wl8WslCaXaE8= Message-ID: Date: Mon, 28 Dec 2020 12:44:18 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: <8f88c925-f12a-6a51-c2b3-c21c55de8dab@FreeBSD.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 28 Dec 2020 20:44:21 -0000 On 12/28/20 12:24 PM, John Baldwin wrote: > I got this panic again today in a VM when quitting a gdb > session after killing a child process via 'kill'. > > panic: Assertion pgrp->pg_jobc > 0 failed at /git/bhyve/sys/kern/kern_proc.c:816 > cpuid = 1 > time = 1609185862 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00946547f0 > vpanic() at vpanic+0x181/frame 0xfffffe0094654840 > panic() at panic+0x43/frame 0xfffffe00946548a0 > _refcount_update_saturated() at _refcount_update_saturated/frame 0xfffffe00946548e0 > killjobc() at killjobc+0x6a6/frame 0xfffffe0094654940 > exit1() at exit1+0x6af/frame 0xfffffe00946549b0 > sys_sys_exit() at sys_sys_exit+0xd/frame 0xfffffe00946549c0 > amd64_syscall() at amd64_syscall+0x12e/frame 0xfffffe0094654af0 > fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe0094654af0 > --- syscall (1, FreeBSD ELF64, sys_sys_exit), rip = 0x8024c8f0a, rsp = 0x7fffffffe358, rbp = 0x7fffffffe370 --- > KDB: enter: panic > [ thread pid 44034 tid 102484 ] > Stopped at kdb_enter+0x37: movq $0,0x10ab066(%rip) > > From what I can tell, the child process that was killed via 'kill' has > not yet exited and is stuck in ptracestop() from fork(): > > (kgdb) where > #0 sched_switch (td=0xfffffe0094001a00, flags=) at /git/bhyve/sys/kern/sched_ule.c:2147 > #1 0xffffffff80bf4015 in mi_switch (flags=266) at /git/bhyve/sys/kern/kern_synch.c:542 > #2 0xffffffff80bfeba5 in thread_suspend_switch (td=, p=) > at /git/bhyve/sys/kern/kern_thread.c:1477 > #3 0xffffffff80bef04b in ptracestop (td=0xfffffe0094001a00, sig=17, si=0x0) > at /git/bhyve/sys/kern/kern_sig.c:2642 > #4 0xffffffff80ba1a54 in fork_return (td=0xfffffe0094001a00, frame=0xfffffe0094671b00) > at /git/bhyve/sys/kern/kern_fork.c:1106 > #5 0xffffffff80ba18b0 in fork_exit (callout=0xffffffff80ba1950 , arg=0xfffffe0094001a00, > frame=0xfffffe0094671b00) at /git/bhyve/sys/kern/kern_fork.c:1069 > #6 > #7 0x00000008007b71aa in ?? () > > kgdb can't find the panicking process due to the zombproc removal, so I will > have to go work on kgdb to recover from that change. :( I've come up with a shorter reproducer (original was trying to debug a perl script in OpenSSL's test suite). Compile this program: #include #include #include #include #include #include int main(void) { pid_t pid, wpid; pid = fork(); if (pid == -1) err(1, "fork"); if (pid == 0) { printf("I'm in the child\n"); exit(1); } printf("I'm in the parent\n"); wpid = waitpid(pid, NULL, 0); if (wpid < 0) err(1, "waitpid"); return (0); } Then in gdb do the following: # gdb101 ./forktest ... (gdb) catch fork Catchpoint 1 (fork) (gdb) r Starting program: /mnt/forktest/forktest Catchpoint 1 (forked process 830), _fork () at _fork.S:4 4 _fork.S: No such file or directory. (gdb) kill Kill the program being debugged? (y or n) y [Inferior 1 (process 828) killed] (gdb) quit -- John Baldwin From owner-freebsd-current@freebsd.org Tue Dec 29 00:38: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 8E1C54C691A for ; Tue, 29 Dec 2020 00:38:08 +0000 (UTC) (envelope-from monochrome@twcny.rr.com) Received: from p-impout004.msg.pkvw.co.charter.net (p-impout004aa.msg.pkvw.co.charter.net [47.43.26.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D4b9q3NJ9z4wYB for ; Tue, 29 Dec 2020 00:38:06 +0000 (UTC) (envelope-from monochrome@twcny.rr.com) Received: from [192.168.13.11] ([45.47.33.158]) by cmsmtp with ESMTP id u31ZkWvMoRW1lu31Zk7nFY; Tue, 29 Dec 2020 00:38:05 +0000 X-Authority-Analysis: v=2.3 cv=bsIy+3Si c=1 sm=1 tr=0 a=VvwePSPmDFBOGFNvGtd2Cw==:117 a=VvwePSPmDFBOGFNvGtd2Cw==:17 a=IkcTkHD0fZMA:10 a=6I5d2MoRAAAA:8 a=m_eqrUm7AAAA:8 a=nM-pA_4vtj8bxs-EnqwA:9 a=QEXdDO2ut3YA:10 a=IjZwj45LgO3ly-622nXo:22 a=gqvgDGpgIgBnLIJhLird:22 Subject: Re: git and the loss of revision numbers To: freebsd-current@freebsd.org References: <54116640-E6A1-4C53-9D7E-4384F942628E@ellael.org> <8ABAC674-89AA-47BE-996C-4DF6E7713F21@ellael.org> <53dd689b-2401-8e90-f332-50c60c549c2e@FreeBSD.org> From: monochrome Message-ID: <1d1e2003-0cc1-6e67-0ceb-f0fcba03f8f7@twcny.rr.com> Date: Mon, 28 Dec 2020 19:38:05 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfItVj04nZS2cEvmamyBd7E4HE57cmarhqwAggCE0pJdHxYX4tQcI34Az9rkGBXrNhY2FoCV2MLD2ZiL17TOHBsa5o4SX1O+COSnmRO3gGZpBhFzFOegF jHIW3o4ftOACtAKnrP9k5hTx1XeptgQrqjou/e1gLny9z09eW65VWuFu/KqWvDelameRz3uz6RGj7A== X-Rspamd-Queue-Id: 4D4b9q3NJ9z4wYB X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.19 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_VERYGOOD(0.00)[47.43.26.135:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:47.43.26.0/24]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[rr.com]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.89)[-0.892]; RCVD_IN_DNSWL_NONE(0.00)[47.43.26.135:from]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:40294, ipnet:47.43.24.0/21, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-current]; RECEIVED_SPAMHAUS_PBL(0.00)[45.47.33.158:received] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 29 Dec 2020 00:38:08 -0000 what would be the git command for reverting source to a previous version using these numbers? for example, with svn and old numbers: svnlite update -r367627 /usr/src this is needed often when it blows up for someone tracking current On 12/28/20 11:27 AM, Ed Maste wrote: > On Mon, 28 Dec 2020 at 07:08, Renato Botelho wrote: >> >> FreeBSD bast.garga.net.br 13.0-CURRENT FreeBSD 13.0-CURRENT #19 >> 3cc0c0d66a0-c255241(main)-dirty: >> ^ >> This is an incremental counter of commits > > Also, uqs@ recently fixed an issue in newvers.sh (including the final, > non-updating svn revision) and reordered the information. An example > of the new format: > > main-c255126-gb81783dc98e6-dirty > \ \ \ \ > \ \ \ local modifications > \ \ hash > \ commit count > branch > _______________________________________________ > 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 Dec 29 00:56:03 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 C393C4C78D6 for ; Tue, 29 Dec 2020 00:56:03 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from mail.nomadlogic.org (mail.nomadlogic.org [174.136.98.114]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.nomadlogic.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D4bZV4FTyz4xjm for ; Tue, 29 Dec 2020 00:56:02 +0000 (UTC) (envelope-from pete@nomadlogic.org) Received: from [192.168.1.160] (cpe-24-24-163-126.socal.res.rr.com [24.24.163.126]) by mail.nomadlogic.org (OpenSMTPD) with ESMTPSA id 96d18c0f (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Tue, 29 Dec 2020 00:56:00 +0000 (UTC) Subject: Re: git and the loss of revision numbers To: monochrome , freebsd-current@freebsd.org References: <54116640-E6A1-4C53-9D7E-4384F942628E@ellael.org> <8ABAC674-89AA-47BE-996C-4DF6E7713F21@ellael.org> <53dd689b-2401-8e90-f332-50c60c549c2e@FreeBSD.org> <1d1e2003-0cc1-6e67-0ceb-f0fcba03f8f7@twcny.rr.com> From: Pete Wright Message-ID: <6a83684d-ee5b-5002-3553-7b383f02768c@nomadlogic.org> Date: Mon, 28 Dec 2020 16:56:00 -0800 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <1d1e2003-0cc1-6e67-0ceb-f0fcba03f8f7@twcny.rr.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Rspamd-Queue-Id: 4D4bZV4FTyz4xjm X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.30 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[nomadlogic.org]; RBL_DBL_DONT_QUERY_IPS(0.00)[174.136.98.114:from]; SPAMHAUS_ZRD(0.00)[174.136.98.114:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:25795, ipnet:174.136.96.0/20, country:US]; 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.34 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, 29 Dec 2020 00:56:03 -0000 On 12/28/20 4:38 PM, monochrome wrote: > what would be the git command for reverting source to a previous > version using these numbers? for example, with svn and old numbers: > svnlite update -r367627 /usr/src > I will generally just checkout the short git hash like so in my local checkout: $ git checkout gb81783dc98e6 you can quickly get the hashes by running "git log" from your checkout. cheers, -pete -- Pete Wright pete@nomadlogic.org @nomadlogicLA From owner-freebsd-current@freebsd.org Tue Dec 29 00:56:41 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 341464C7AD5 for ; Tue, 29 Dec 2020 00:56:41 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D4bbD3Zdbz4xqD for ; Tue, 29 Dec 2020 00:56:40 +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 0BT0udgR052914 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 28 Dec 2020 16:56:39 -0800 (PST) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id 0BT0udLL052912; Mon, 28 Dec 2020 16:56:39 -0800 (PST) (envelope-from jmg) Date: Mon, 28 Dec 2020 16:56:39 -0800 From: John-Mark Gurney To: monochrome Cc: freebsd-current@freebsd.org Subject: Re: git and the loss of revision numbers Message-ID: <20201229005639.GS31099@funkthat.com> Mail-Followup-To: monochrome , freebsd-current@freebsd.org References: <54116640-E6A1-4C53-9D7E-4384F942628E@ellael.org> <8ABAC674-89AA-47BE-996C-4DF6E7713F21@ellael.org> <53dd689b-2401-8e90-f332-50c60c549c2e@FreeBSD.org> <1d1e2003-0cc1-6e67-0ceb-f0fcba03f8f7@twcny.rr.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1d1e2003-0cc1-6e67-0ceb-f0fcba03f8f7@twcny.rr.com> X-Operating-System: FreeBSD 11.3-STABLE amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Mon, 28 Dec 2020 16:56:39 -0800 (PST) X-Rspamd-Queue-Id: 4D4bbD3Zdbz4xqD X-Spamd-Bar: - X-Spamd-Result: default: False [-1.80 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[jmg]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[funkthat.com]; RBL_DBL_DONT_QUERY_IPS(0.00)[208.87.223.18:from]; AUTH_NA(1.00)[]; SPAMHAUS_ZRD(0.00)[208.87.223.18:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-1.000]; 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.34 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, 29 Dec 2020 00:56:41 -0000 monochrome wrote this message on Mon, Dec 28, 2020 at 19:38 -0500: > what would be the git command for reverting source to a previous version > using these numbers? for example, with svn and old numbers: > svnlite update -r367627 /usr/src > > this is needed often when it blows up for someone tracking current Get the hash from a commit number: $git rev-list --reverse HEAD | tail -n +255241 | head -n 1 3cc0c0d66a065554459bd2f9b4f80cc07426464a so: git checkout $(git rev-list --reverse HEAD | tail -n +255240 | head -n 1) > On 12/28/20 11:27 AM, Ed Maste wrote: > > On Mon, 28 Dec 2020 at 07:08, Renato Botelho wrote: > >> > >> FreeBSD bast.garga.net.br 13.0-CURRENT FreeBSD 13.0-CURRENT #19 > >> 3cc0c0d66a0-c255241(main)-dirty: > >> ^ > >> This is an incremental counter of commits > > > > Also, uqs@ recently fixed an issue in newvers.sh (including the final, > > non-updating svn revision) and reordered the information. An example > > of the new format: > > > > main-c255126-gb81783dc98e6-dirty > > \ \ \ \ > > \ \ \ local modifications > > \ \ hash > > \ commit count > > branch -- 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 Tue Dec 29 01:03:28 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 DC1444C7F73 for ; Tue, 29 Dec 2020 01:03:28 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D4bl40F52z4yQN; Tue, 29 Dec 2020 01:03:27 +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 0BT13Pau053197 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 28 Dec 2020 17:03:26 -0800 (PST) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id 0BT13Pqp053196; Mon, 28 Dec 2020 17:03:25 -0800 (PST) (envelope-from jmg) Date: Mon, 28 Dec 2020 17:03:25 -0800 From: John-Mark Gurney To: Kurt Jaeger Cc: freebsd-current@freebsd.org Subject: Re: HEADS UP: FreeBSD src repo transitioning to git this weekend Message-ID: <20201229010325.GT31099@funkthat.com> Mail-Followup-To: Kurt Jaeger , freebsd-current@freebsd.org References: <31ab8015-a0c4-af77-0ead-a17da0f88f1d@freebsd.org> <5fdc0b90.1c69fb81.866eb.8c29SMTPIN_ADDED_MISSING@mx.google.com> <20201218175241.GA72552@spindle.one-eyed-alien.net> <20201218182820.1P0tK%steffen@sdaoden.eu> <20201223023242.GG31099@funkthat.com> 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]); Mon, 28 Dec 2020 17:03:26 -0800 (PST) X-Rspamd-Queue-Id: 4D4bl40F52z4yQN X-Spamd-Bar: - X-Spamd-Result: default: False [-1.80 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[jmg]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[funkthat.com]; RBL_DBL_DONT_QUERY_IPS(0.00)[208.87.223.18:from]; AUTH_NA(1.00)[]; SPAMHAUS_ZRD(0.00)[208.87.223.18:from:127.0.2.255]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-0.999]; 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.34 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, 29 Dec 2020 01:03:28 -0000 Kurt Jaeger wrote this message on Wed, Dec 23, 2020 at 13:15 +0100: > Hi! > > > It's also hard to collect ALL the keys of the devs at any point in > > time to decide if that key is authorized to sign a commit in the > > repo... > > We do have most of the keys in docs/share/pgpkeys/ plus history. > > > Like if a dev starts in 2021, any commits made by that > > dev prior to 2021 should not be "valid".. Then there's also the > > issue that people's keys change over time, and now you need to know > > what time period each key was valid for, otherwise a compromised key > > could be used to insert malicious changes into your/the tree... > > If we manage keys plus their history in the doc repo, this seems > to be solved. The data is there, but are you going to write a tool such that it can be verified? Then you have the job of verifying the doc repo to make sure that the keys you have is valid, where does the root of trust come from there? Not saying it isn't possible, it's just a LOT of work to make it useful... -- 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 Tue Dec 29 01:06: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 91FCA4C859E for ; Tue, 29 Dec 2020 01:06:34 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mx.catwhisker.org (mx.catwhisker.org [107.204.234.170]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4D4bpd4gMNz4yRj for ; Tue, 29 Dec 2020 01:06:33 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.16.1/8.15.2) with ESMTP id 0BT16Qeq016818 for ; Tue, 29 Dec 2020 01:06:26 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.16.1/8.16.1/Submit) id 0BT16QmM016817 for freebsd-current@freebsd.org; Mon, 28 Dec 2020 17:06:26 -0800 (PST) (envelope-from david) Date: Mon, 28 Dec 2020 17:06:26 -0800 From: David Wolfskill To: freebsd-current@freebsd.org Subject: Re: git and the loss of revision numbers Message-ID: Reply-To: current@freebsd.org Mail-Followup-To: current@freebsd.org, freebsd-current@freebsd.org References: <54116640-E6A1-4C53-9D7E-4384F942628E@ellael.org> <8ABAC674-89AA-47BE-996C-4DF6E7713F21@ellael.org> <53dd689b-2401-8e90-f332-50c60c549c2e@FreeBSD.org> <1d1e2003-0cc1-6e67-0ceb-f0fcba03f8f7@twcny.rr.com> <20201229005639.GS31099@funkthat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="/0TPpVhDBVQOvb2J" Content-Disposition: inline In-Reply-To: <20201229005639.GS31099@funkthat.com> X-Rspamd-Queue-Id: 4D4bpd4gMNz4yRj X-Spamd-Bar: ----- X-Spamd-Result: default: False [-5.15 / 15.00]; HAS_REPLYTO(0.00)[current@freebsd.org]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[david]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[107.204.234.170:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:107.204.234.170]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; REPLYTO_DOM_NEQ_FROM_DOM(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[107.204.234.170:from:127.0.2.255]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.75)[-0.752]; DMARC_NA(0.00)[catwhisker.org]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; RCVD_TLS_LAST(0.00)[]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:7018, ipnet:107.192.0.0/12, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 29 Dec 2020 01:06:34 -0000 --/0TPpVhDBVQOvb2J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Dec 28, 2020 at 04:56:39PM -0800, John-Mark Gurney wrote: > monochrome wrote this message on Mon, Dec 28, 2020 at 19:38 -0500: > > what would be the git command for reverting source to a previous versio= n=20 > > using these numbers? for example, with svn and old numbers: > > svnlite update -r367627 /usr/src > >=20 > > this is needed often when it blows up for someone tracking current >=20 > Get the hash from a commit number: > $git rev-list --reverse HEAD | tail -n +255241 | head -n 1 > 3cc0c0d66a065554459bd2f9b4f80cc07426464a >=20 > so: > git checkout $(git rev-list --reverse HEAD | tail -n +255240 | head -n 1) > .... Or save a process: git rev-list --reverse HEAD | awk 'NR =3D=3D 255241 {print; exit 0}' 3cc0c0d66a065554459bd2f9b4f80cc07426464a (And thus: git checkout $(git rev-list --reverse HEAD | awk 'NR =3D=3D 255241 {print; = exit 0}') Could also pass the number to awk via the "-v var=3Dvalue" command-line.) Peace, david --=20 David H. Wolfskill david@catwhisker.org While Trump successfully conned a lot of people for a while, in the end he's just a failure throwing a temper tantrum because he lost. See https://www.catwhisker.org/~david/publickey.gpg for my public key. --/0TPpVhDBVQOvb2J Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAEBCgB9FiEE4owz2QxMJyaxAefyQLJg+bY2PckFAl/qgRJfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEUy OEMzM0Q5MEM0QzI3MjZCMTAxRTdGMjQwQjI2MEY5QjYzNjNEQzkACgkQQLJg+bY2 Pcn7nAf9FFcmQJqZjD4LBGpmk5Jy+FGIrc5kOpnH+jbo/Lo4z24rUB+jzy2aQQKn Cpaz+2Tt5B0GeW6u++qsIKZc9SvOm3btr/RnKg9JGHRvyw4erHyLUozzWV+EAAfT YynXLNfw/RKnq3RPgE1eyLCQi7nMziVYDy6JgUMz1sg0tlzGSrVTA9chmmEGqdl2 bVAxkmGZS15qvLr+bRaRqVqhA4OEDVezKdIXy5RRe8XZwCLP01NDPiRVMpOtq5Va prWiY0FP5opcCm4yvgTKTs7f1kprUMaBbSH4KpaSDqGRi2b1QGlcF3nJ+eXrCKsr JryDc/6WlkrFMcnhrGyHzWD/rbPJsw== =ZAOG -----END PGP SIGNATURE----- --/0TPpVhDBVQOvb2J-- From owner-freebsd-current@freebsd.org Tue Dec 29 01:19:43 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 13EFC4C9142 for ; Tue, 29 Dec 2020 01:19:43 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D4c5p0R66z510X; Tue, 29 Dec 2020 01:19:41 +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 0BT1JdPp053569 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 28 Dec 2020 17:19:39 -0800 (PST) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id 0BT1JdUA053568; Mon, 28 Dec 2020 17:19:39 -0800 (PST) (envelope-from jmg) Date: Mon, 28 Dec 2020 17:19:39 -0800 From: John-Mark Gurney To: Brooks Davis , Thomas Mueller , freebsd-current@freebsd.org Subject: Re: HEADS UP: FreeBSD src repo transitioning to git this weekend Message-ID: <20201229011939.GU31099@funkthat.com> Mail-Followup-To: Brooks Davis , Thomas Mueller , freebsd-current@freebsd.org References: <31ab8015-a0c4-af77-0ead-a17da0f88f1d@freebsd.org> <5fdc0b90.1c69fb81.866eb.8c29SMTPIN_ADDED_MISSING@mx.google.com> <20201218175241.GA72552@spindle.one-eyed-alien.net> <20201218182820.1P0tK%steffen@sdaoden.eu> <20201223023242.GG31099@funkthat.com> <20201223162417.v7Ce6%steffen@sdaoden.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201223162417.v7Ce6%steffen@sdaoden.eu> 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]); Mon, 28 Dec 2020 17:19:39 -0800 (PST) X-Rspamd-Queue-Id: 4D4c5p0R66z510X X-Spamd-Bar: / X-Spamd-Result: default: False [0.20 / 15.00]; RCVD_TLS_ALL(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)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[funkthat.com]; RBL_DBL_DONT_QUERY_IPS(0.00)[208.87.223.18:from]; AUTH_NA(1.00)[]; NEURAL_SPAM_SHORT(1.00)[1.000]; SPAMHAUS_ZRD(0.00)[208.87.223.18:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; FREEMAIL_TO(0.00)[freebsd.org,twc.com]; 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.34 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, 29 Dec 2020 01:19:43 -0000 Steffen Nurpmeso wrote this message on Wed, Dec 23, 2020 at 17:24 +0100: > |Then there's also the point that the repo is (looks like it) using > |SHA-1 hashes, which are effectively broken, so depending upon them > |to validate the tree is questionable anyways. > > git uses the hardened SHA-1 for sure, which is, as far as i know, > at least safe against the known attack. > I .. have not tracked this, but i think upgrading to SHA-256 is > possible, once this will become standard. Just even more > metadata, then. I have not looked into this, still in progress. A new attack came out earlier this year: https://eprint.iacr.org/2020/014.pdf >From the paper: > In particular, chosen-prefix collisions can break signature schemes and > handshake security in secure channel protocols (TLS, SSH), if generated > extremely quickly. The previous attack in 2017 did not break SHA-1 enough to render it's use by git vulnerable, but the writing was on the wall for SHA-1... I believe this new attack makes git's use a SHA-1 vulnerable... The type/length prefix that prevented the previous attacks from working is not effective against the new attack... Also, the cost of the attack is not great ($45k), considering the recent SolarWinds supply chain attack, being able to smuggle a modified file into a git repo, say an OS's build server, such that the tools don't know the tree is modified is a real problem... -- 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 Tue Dec 29 01:37:23 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 8188A4CA77D for ; Tue, 29 Dec 2020 01:37:23 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature 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 4D4cVB3Ztjz52lG for ; Tue, 29 Dec 2020 01:37:22 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x734.google.com with SMTP id p14so10385056qke.6 for ; Mon, 28 Dec 2020 17:37:22 -0800 (PST) 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; bh=d9wRnLjAKH063SZbvl5r4Z4jYQ3YBFoNaSytZfE1o4E=; b=d1j5hQL1k7LA21/DByy0MD1NRiR7lUV65rXj+Ar0VLAKWcsgHZTIRD6FOR1dFiVReS qd18xhsb1Qsw1ptzaDe4+Pc53ejfbWDpv2jtkcszwZ+9tWeDL2oRr7WN4kLf2PYnOebO nSjs2HMNZVnsnfJBd0ODSWMi9RXtXdsy6VsBUyV72yJu+3XaHcf2ArrvyYrklzq+M5lc QDj3psYzb93R0rRJCADm2nHM1Bx9XDd0fTdRtrRx2o/pos/rIFBrY7EsdRcp2H80du2x fahTgEQfum98Z7Ve3Mfww6jPKDLYXFaJFfHpwSTmvwPewonv8qRetBBBzl9/MscwPqc1 /ZmA== X-Gm-Message-State: AOAM532ryIV1Pwo90Q7RHctW3tT8RhNAyVcu+Zw8L7iotDrRWKXjkAye KohmtgvLzLkPopWWUD0uziOKtivb6zq9gMapiBjcwA== X-Google-Smtp-Source: ABdhPJz/UlWj06Xke1PmDY42EOWNQF1IGXJMImmIbYQ0urVST9v19EAye/jJ2PezVASRXxW3MII5Ra2Ru2Alf1+d2ig= X-Received: by 2002:a37:a614:: with SMTP id p20mr46007355qke.359.1609205840923; Mon, 28 Dec 2020 17:37:20 -0800 (PST) MIME-Version: 1.0 References: <31ab8015-a0c4-af77-0ead-a17da0f88f1d@freebsd.org> <5fdc0b90.1c69fb81.866eb.8c29SMTPIN_ADDED_MISSING@mx.google.com> <20201218175241.GA72552@spindle.one-eyed-alien.net> <20201218182820.1P0tK%steffen@sdaoden.eu> <20201223023242.GG31099@funkthat.com> <20201223162417.v7Ce6%steffen@sdaoden.eu> <20201229011939.GU31099@funkthat.com> In-Reply-To: <20201229011939.GU31099@funkthat.com> From: Warner Losh Date: Mon, 28 Dec 2020 18:37:08 -0700 Message-ID: Subject: Re: HEADS UP: FreeBSD src repo transitioning to git this weekend To: Brooks Davis , Thomas Mueller , freebsd-current@freebsd.org X-Rspamd-Queue-Id: 4D4cVB3Ztjz52lG X-Spamd-Bar: - X-Spamd-Result: default: False [-1.00 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; NEURAL_SPAM_SHORT(1.00)[1.000]; SPAMHAUS_ZRD(0.00)[2607:f8b0:4864:20::734:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::734:from]; R_SPF_NA(0.00)[no SPF record]; FREEMAIL_TO(0.00)[freebsd.org,twc.com]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RBL_DBL_DONT_QUERY_IPS(0.00)[2607:f8b0:4864:20::734:from]; 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.34 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 29 Dec 2020 01:37:23 -0000 On Mon, Dec 28, 2020, 6:19 PM John-Mark Gurney wrote: > Steffen Nurpmeso wrote this message on Wed, Dec 23, 2020 at 17:24 +0100: > > |Then there's also the point that the repo is (looks like it) using > > |SHA-1 hashes, which are effectively broken, so depending upon them > > |to validate the tree is questionable anyways. > > > > git uses the hardened SHA-1 for sure, which is, as far as i know, > > at least safe against the known attack. > > I .. have not tracked this, but i think upgrading to SHA-256 is > > possible, once this will become standard. Just even more > > metadata, then. I have not looked into this, still in progress. > > A new attack came out earlier this year: > https://eprint.iacr.org/2020/014.pdf > > From the paper: > > In particular, chosen-prefix collisions can break signature schemes and > > handshake security in secure channel protocols (TLS, SSH), if generated > > extremely quickly. > > The previous attack in 2017 did not break SHA-1 enough to render it's > use by git vulnerable, but the writing was on the wall for SHA-1... > > I believe this new attack makes git's use a SHA-1 vulnerable... > The type/length prefix that prevented the previous attacks from > working is not effective against the new attack... > > Also, the cost of the attack is not great ($45k), considering the recent > SolarWinds supply chain attack, being able to smuggle a modified file > into a git repo, say an OS's build server, such that the tools don't > know the tree is modified is a real problem... > Yea. The git transition team knew about these issues (though the referenced paper is new). Too bad git's SHA-256 stuff is too immature to use yet at scale, coupled with requiring a super new git version to even test it out. Plus, much of the greater git ecosystem simply doesn't support SHA-256 yet. We should, as a project, continue to test how well it works and monitor the ecosystem for a transition in a few years when it is robust... Warner -- > John-Mark Gurney Voice: +1 415 225 5579 > > "All that I will do, has been done, All that I have, has not." > _______________________________________________ > 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 Dec 29 03:12:53 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 DD3DA4CDF93 for ; Tue, 29 Dec 2020 03:12:53 +0000 (UTC) (envelope-from monochrome@twcny.rr.com) Received: from p-impout005.msg.pkvw.co.charter.net (p-impout005aa.msg.pkvw.co.charter.net [47.43.26.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D4fcP0k3zz57YG for ; Tue, 29 Dec 2020 03:12:52 +0000 (UTC) (envelope-from monochrome@twcny.rr.com) Received: from [192.168.13.11] ([45.47.33.158]) by cmsmtp with ESMTP id u5RFkWOxMiNLEu5RFk4lc8; Tue, 29 Dec 2020 03:12:45 +0000 X-Authority-Analysis: v=2.3 cv=QJYWuTDL c=1 sm=1 tr=0 a=VvwePSPmDFBOGFNvGtd2Cw==:117 a=VvwePSPmDFBOGFNvGtd2Cw==:17 a=IkcTkHD0fZMA:10 a=1EJVf5MaRCBXdaUkzkkA:9 a=QEXdDO2ut3YA:10 Subject: Re: git and the loss of revision numbers To: freebsd-current@freebsd.org References: <54116640-E6A1-4C53-9D7E-4384F942628E@ellael.org> <8ABAC674-89AA-47BE-996C-4DF6E7713F21@ellael.org> <53dd689b-2401-8e90-f332-50c60c549c2e@FreeBSD.org> <1d1e2003-0cc1-6e67-0ceb-f0fcba03f8f7@twcny.rr.com> <6a83684d-ee5b-5002-3553-7b383f02768c@nomadlogic.org> From: monochrome Message-ID: <9087b1bb-9e44-bb61-4514-72f99a36d1f5@twcny.rr.com> Date: Mon, 28 Dec 2020 22:12:44 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <6a83684d-ee5b-5002-3553-7b383f02768c@nomadlogic.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfILryAv6HyOEnRgYWEO0slQk9KULu/0KHoLg0FzDMO/gub1OHvQmwxqOCKtOpRPJETZPBRvXr8FOO6WfHmu2umeB4Pbd+OT7aytPv9y+0HBu7r7jN1bg zkqkbaprv/LCxT4WQgF2gqZv9SkdPhnCHymEWnnuRWDJY80uRtq7jkIfBEv0ZSqy7VbvjjNIx6lXsA== X-Rspamd-Queue-Id: 4D4fcP0k3zz57YG X-Spamd-Bar: - X-Spamd-Result: default: False [-1.30 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[47.43.26.136:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:47.43.26.0/24]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[rr.com]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[47.43.26.136:from:127.0.2.255]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_SPAM_SHORT(1.00)[1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:40294, ipnet:47.43.24.0/21, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-current]; RECEIVED_SPAMHAUS_PBL(0.00)[45.47.33.158:received] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 29 Dec 2020 03:12:53 -0000 this didn't seem to work, and now git is saying: You are not currently on a branch. since the incremental numbers aren't in the git log does it make more sense to use the short hash like this? other different responses were focused on the incremental commit number. Also, I saw someone mention that a 12 digit shortened hash is the standard to use, yet uname only spits out 9? thanks On 12/28/20 7:56 PM, Pete Wright wrote: > > On 12/28/20 4:38 PM, monochrome wrote: >> what would be the git command for reverting source to a previous >> version using these numbers? for example, with svn and old numbers: >> svnlite update -r367627 /usr/src >> > I will generally just checkout the short git hash like so in my local > checkout: > $ git checkout gb81783dc98e6 > > you can quickly get the hashes by running "git log" from your checkout. > > cheers, > -pete > From owner-freebsd-current@freebsd.org Tue Dec 29 03:33: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 10EDC4CE8CC for ; Tue, 29 Dec 2020 03:33:26 +0000 (UTC) (envelope-from monochrome@twcny.rr.com) Received: from p-impout003.msg.pkvw.co.charter.net (p-impout003aa.msg.pkvw.co.charter.net [47.43.26.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D4g444sN4z5944 for ; Tue, 29 Dec 2020 03:33:24 +0000 (UTC) (envelope-from monochrome@twcny.rr.com) Received: from [192.168.13.11] ([45.47.33.158]) by cmsmtp with ESMTP id u5lCkZvIjIuTJu5lCkCAKd; Tue, 29 Dec 2020 03:33:23 +0000 X-Authority-Analysis: v=2.3 cv=S/SnP7kP c=1 sm=1 tr=0 a=VvwePSPmDFBOGFNvGtd2Cw==:117 a=VvwePSPmDFBOGFNvGtd2Cw==:17 a=IkcTkHD0fZMA:10 a=kfySaowB4s78lt3uwIkA:9 a=QEXdDO2ut3YA:10 Subject: Re: git and the loss of revision numbers To: freebsd-current@freebsd.org References: <54116640-E6A1-4C53-9D7E-4384F942628E@ellael.org> <8ABAC674-89AA-47BE-996C-4DF6E7713F21@ellael.org> <53dd689b-2401-8e90-f332-50c60c549c2e@FreeBSD.org> <1d1e2003-0cc1-6e67-0ceb-f0fcba03f8f7@twcny.rr.com> <6a83684d-ee5b-5002-3553-7b383f02768c@nomadlogic.org> From: monochrome Message-ID: <8fb16182-e590-6bf0-747f-bc820dea1a3e@twcny.rr.com> Date: Mon, 28 Dec 2020 22:33:22 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <6a83684d-ee5b-5002-3553-7b383f02768c@nomadlogic.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfEGqolnnyw1GLmeCAHHNPEnIAdeQBYlyg4JTLp1vPid9Zh9PJiQChqY87ZTpweaqYpDQjxwAZV+jzhFXIsQh/9+ljxFDlaWMTRn65rJIeqaV6d1gACGn h3d73480nuBSI3hiCLsa/1kHtodT22EVg2LWQQeoiVmgIbg0at5wZeHAwNz9Ik6ulDzktViMweC6KA== X-Rspamd-Queue-Id: 4D4g444sN4z5944 X-Spamd-Bar: - X-Spamd-Result: default: False [-1.30 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[45.47.33.158:received]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[47.43.26.134:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:47.43.26.0/24]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[rr.com]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[47.43.26.134:from:127.0.2.255]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_SPAM_SHORT(1.00)[0.999]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_IN_DNSWL_NONE(0.00)[47.43.26.134:from]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:40294, ipnet:47.43.24.0/21, country:US]; MIME_TRACE(0.00)[0:+]; MAILMAN_DEST(0.00)[freebsd-current]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 29 Dec 2020 03:33:26 -0000 sry forgot details: source tree @ ead01bfe8 git -C /usr/src checkout gf20c0e331 error: pathspec 'gf20c0e331' did not match any file(s) known to git what is the 'g' for? git -C /usr/src checkout f20c0e331 M sys/amd64/conf/GENERIC HEAD is now at f20c0e331 caroot: drop $FreeBSD$ expansion from root bundle yet I don't see any indication that anything changed, and now it wont update at all: git -C /usr/src pull --ff-only You are not currently on a branch. Please specify which branch you want to merge with. See git-pull(1) for details. git pull On 12/28/20 7:56 PM, Pete Wright wrote: > > On 12/28/20 4:38 PM, monochrome wrote: >> what would be the git command for reverting source to a previous >> version using these numbers? for example, with svn and old numbers: >> svnlite update -r367627 /usr/src >> > I will generally just checkout the short git hash like so in my local > checkout: > $ git checkout gb81783dc98e6 > > you can quickly get the hashes by running "git log" from your checkout. > > cheers, > -pete > From owner-freebsd-current@freebsd.org Tue Dec 29 09:11:31 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 1736E4D603D for ; Tue, 29 Dec 2020 09:11:31 +0000 (UTC) (envelope-from blackfoxx@online.de) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.133]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.kundenserver.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D4pZ93JB3z3lH5 for ; Tue, 29 Dec 2020 09:11:29 +0000 (UTC) (envelope-from blackfoxx@online.de) Received: from [192.168.1.60] ([80.153.188.170]) by mrelayeu.kundenserver.de (mreue010 [212.227.15.167]) with ESMTPSA (Nemesis) id 1MXXhv-1kWh9c1uhz-00Z17i for ; Tue, 29 Dec 2020 10:11:27 +0100 To: freebsd-current@freebsd.org From: blackfoxx Subject: Need some help with audio/sound (to get S/PDIF Toslink to work). Message-ID: Date: Tue, 29 Dec 2020 10:12:42 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: de-DE Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:VHvXiot1HUaJxhTD7whru6K1lnoz9cujQyVqA2favSU/ktlz6rq kG5fwMtACQYc2ti2IpUSKx9Y8tZhZuxFSgVoYxAiikHFZ7X1+9AhZnQ9tIXeikdkq+UqHca Qd82aDNoJTFjS788Uw5J2LQVWV4ATadjSvuplmiXYS6g5AR/8tP0ZycFZptLVj1x4t1zaku honr+P41ZIl/p3ikxDY7A== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:rJu67sJMzVE=:nCkpS9c7++nbav+8Fl/213 y5Hbu0mmlzF7BLdoDDzK1sMMUaxgP7iyCiRtlZnY+CnTbfhhrgrzL3gzWvMPa+rM3lEU82Vtw TIIVhbNKKHgdK2J6nwUerp6VYDUQNAeZrQJU9UGO2SRvwQHqRInQB1BRAIaeB7YfbJL8IyKTR qKOtWvK6z7/8qSzRiAdMctlfE4nwQuH4QFkG8Dzb+kaWUALamk53Blx30a2IETwrk2AehVznm UB7b9CwzaTJa9zzFPBwGOOAvLVD4TKlGiGmjflj3hFWbQd14kmt+BygqoY4acKExLeWXlGLl7 kncPaMwtVjUGegpfFUj56u4vYXaQmIMA3MdETowoBtJVPKPCIxR8ljxc7Z4GTTdJ8zESadhaS 4/Vn0kh8LiCs8s1zpViphGJ7aUCyBvN2FfRKjaq/wmr+Q9I1kLhproJqwlsNFK8T+rcdf0rtg m3cnMAUwnw== X-Rspamd-Queue-Id: 4D4pZ93JB3z3lH5 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.30 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[212.227.126.133:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:212.227.126.128/25]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[212.227.126.133:from:127.0.2.255]; ARC_NA(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_IN_DNSWL_NONE(0.00)[212.227.126.133:from]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DMARC_NA(0.00)[online.de]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-current]; RWL_MAILSPIKE_POSSIBLE(0.00)[212.227.126.133:from] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 29 Dec 2020 09:11:31 -0000 Hi there. I'm using FreeBSD (13.0-CURRENT) since 09/2020 at my Raspberry Pi 4B as Home-and-Web-Server-OS with Apache, PHP, SQLite etc... And it works like a charm! Furthermore I'm trying to switch with my main workstation from Win10 to FreeBSD too. Because the more I'm working with FreeBSD, the more I realize that it's the only sane OS out there. Now, I really would like to remove my Win10 Installation, but unfortunately I still have an issue with FreeBSD 13.0-CURRENT for which I can't find solutions, even after reading the whole handbook and searching the www for weeks: I've got an "SoundBlaster Audigy Rx" Soundcard with "Creative E-MU CA10300" Chipset, using the BSDs "EMU10Kx" Kernel Module. The mixer shows all in/outputs right and volume-control of all analog I/Os is working fine with my "Behringer MS40" Speakers and "Alienware TactX" Headset. BUT the digital output (S/PDIF, Toslink) does NOT work. Even if I set dig1/dig2/dig3 and all other outputs to "100:100" within the mixer - still no sound via Toslink. With Devuan (ALSA) or Win10 (native Creative Driver) it is working properly. So it can't be a hardware issue. I also tried OSS, ALSA and PulseAudio with FreeBSD, searched the web for hours, tried this and that, but still no sound via Toslink... (Fortunately) this is the only Hardware-Issue I have. But it is important to me to get S/PDIF Toslink to work! I hope that someone around here can give me some hints, advice, solutions... Regards, blackfoxx My Hardware-Setup: http://www.sysprofile.de/id182580 dmesg.boot: [1] ---<>--- [1] Copyright (c) 1992-2020 The FreeBSD Project. [1] Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 [1] The Regents of the University of California. All rights reserved. [1] FreeBSD is a registered trademark of The FreeBSD Foundation. [1] FreeBSD 13.0-CURRENT #0 : Sat Dec 26 23:08:09 UTC 2020 [1] FreeBSD clang version 11.0.0 (git@github.com:llvm/llvm-project.git llvmorg-11.0.0-rc2-0-g414f32a9e86) [1] WARNING: WITNESS option enabled, expect reduced performance. [1] VT(efifb): resolution 1280x800 [1] FreeBSD: initialize and check features (__FreeBSD_version 1300133). [1] CPU: Intel(R) Core(TM) i7-3820 CPU @ 3.60GHz (3200.19-MHz K8-class CPU) [1] Origin="GenuineIntel" Id=0x206d7 Family=0x6 Model=0x2d Stepping=7 [1]Features=0xbfebfbff [1]Features2=0x1fbee3bf [1] AMD Features=0x2c100800 [1] AMD Features2=0x1 [1] XSAVE Features=0x1 [1] VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID [1] TSC: P-state invariant, performance statistics [1] real memory = 17179869184 (16384 MB) [1] avail memory = 16491573248 (15727 MB) [1] Event timer "LAPIC" quality 600 [1] ACPI APIC Table: [1] FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs [1] FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 hardware threads [1] FreeBSD/SMP Online: 1 package(s) x 4 core(s) [1] random: unblocking device. [1] Firmware Warning (ACPI): 32/64X length mismatch in FADT/Pm1aEventBlock: 32/16 (20201113/tbfadt-748) [1] Firmware Warning (ACPI): 32/64X length mismatch in FADT/PmTimerBlock: 32/24 (20201113/tbfadt-748) [1] Firmware Warning (ACPI): Invalid length for FADT/Pm1aEventBlock: 16, using default 32 (20201113/tbfadt-850) [1] Firmware Warning (ACPI): Invalid length for FADT/PmTimerBlock: 24, using default 32 (20201113/tbfadt-850) [1] ioapic1 irqs 24-47 [1] ioapic0 irqs 0-23 [1] Launching APs: 2 1 3 [1] random: entropy device external interface [1] WARNING: Device "kbd" is Giant locked and may be deleted before FreeBSD 13.0. [1] kbd1 at kbdmux0 [1] 000.000039 [4346] netmap_init netmap: loaded module [1] [ath_hal] loaded [1] nvidia-modeset: Loading NVIDIA Kernel Mode Setting Driver for UNIX platforms 440.100 Fri May 29 08:11:49 UTC 2020 [1] nexus0 [1] efirtc0: [1] efirtc0: registered as a time-of-day clock, resolution 1.000000s [1] cryptosoft0: [1] aesni0: [1] acpi0: [1] acpi0: Power Button (fixed) [1] cpu0: on acpi0 [1] atrtc0: port 0x70-0x71,0x74-0x77 irq 8 on acpi0 [1] atrtc0: registered as a time-of-day clock, resolution 1.000000s [1] Event timer "RTC" frequency 32768 Hz quality 0 [1] attimer0: port 0x40-0x43,0x50-0x53 irq 0 on acpi0 [1] Timecounter "i8254" frequency 1193182 Hz quality 0 [1] Event timer "i8254" frequency 1193182 Hz quality 100 [1] hpet0: iomem 0xfed00000-0xfed03fff on acpi0 [1] Timecounter "HPET" frequency 14318180 Hz quality 950 [1] Event timer "HPET" frequency 14318180 Hz quality 550 [1] Event timer "HPET1" frequency 14318180 Hz quality 440 [1] Event timer "HPET2" frequency 14318180 Hz quality 440 [1] Event timer "HPET3" frequency 14318180 Hz quality 440 [1] Event timer "HPET4" frequency 14318180 Hz quality 440 [1] Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 [1] acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 [1] acpi_button0: on acpi0 [1] pcib0: port 0xcf8-0xcff on acpi0 [1] pci0: on pcib0 [1] pcib1: at device 1.0 on pci0 [1] pci1: on pcib1 [1] pcib2: at device 1.1 on pci0 [1] pci2: on pcib2 [1] xhci0: mem 0xeb300000-0xeb301fff irq 16 at device 0.0 on pci2 [1] xhci0: 32 bytes context size, 32-bit DMA [1] usbus0: waiting for BIOS to give up control [1] usbus0 on xhci0 [1] usbus0: 5.0Gbps Super Speed USB v3.0 [1] pcib3: at device 2.0 on pci0 [1] pci3: on pcib3 [1] xhci1: mem 0xeb200000-0xeb201fff irq 16 at device 0.0 on pci3 [1] xhci1: 64 bytes context size, 32-bit DMA [1] usbus1: waiting for BIOS to give up control [1] usbus1: timed out waiting for BIOS [1] usbus1 on xhci1 [1] usbus1: 5.0Gbps Super Speed USB v3.0 [1] pcib4: at device 3.0 on pci0 [1] pci4: on pcib4 [1] vgapci0: port 0x2000-0x207f mem 0xea000000-0xeaffffff,0xe0000000-0xe7ffffff,0xe8000000-0xe9ffffff irq 16 at device 0.0 on pci4 [1] nvidia0: on vgapci0 [1] vgapci0: child nvidia0 requested pci_enable_io [1] vgapci0: child nvidia0 requested pci_enable_io [1] vgapci0: Boot video device [1] hdac0: mem 0xeb000000-0xeb003fff irq 17 at device 0.1 on pci4 [1] pcib5: at device 17.0 on pci0 [1] pci5: on pcib5 [1] pci0: at device 22.0 (no driver attached) [1] em0: port 0x3040-0x305f mem 0xeb400000-0xeb41ffff,0xeb421000-0xeb421fff irq 20 at device 25.0 on pci0 [1] em0: Using 1024 TX descriptors and 1024 RX descriptors [1] em0: Using an MSI interrupt [1] em0: Ethernet address: 54:be:f7:08:d6:34 [1] em0: netmap queues/slots: TX 1/1024, RX 1/1024 [1] ehci0: mem 0xeb501000-0xeb5013ff irq 16 at device 26.0 on pci0 [1] usbus2: EHCI version 1.0 [1] usbus2 on ehci0 [1] usbus2: 480Mbps High Speed USB v2.0 [1] pcib6: at device 28.0 on pci0 [1] pci6: on pcib6 [1] pcib7: mem 0xeb100000-0xeb10ffff at device 0.0 on pci6 [1] pci7: on pcib7 [1] emu10kx0: port 0x1000-0x103f irq 16 at device 0.0 on pci7 [1] pcm0: on emu10kx0 [1] pcm0: [1] pcm1: on emu10kx0 [1] pcm2: on emu10kx0 [1] pcm3: on emu10kx0 [1] ehci1: mem 0xeb502000-0xeb5023ff irq 23 at device 29.0 on pci0 [1] usbus3: EHCI version 1.0 [1] usbus3 on ehci1 [1] usbus3: 480Mbps High Speed USB v2.0 [1] pcib8: at device 30.0 on pci0 [1] pci8: on pcib8 [1] isab0: at device 31.0 on pci0 [1] isa0: on isab0 [1] ahci0: port 0x3068-0x306f,0x3074-0x3077,0x3060-0x3067,0x3070-0x3073,0x3020-0x303f mem 0xeb423000-0xeb4237ff irq 18 at device 31.2 on pci0 [1] ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier not supported [1] ahcich0: at channel 0 on ahci0 [1] ahcich1: at channel 1 on ahci0 [1] ahcich2: at channel 2 on ahci0 [1] ahcich3: at channel 3 on ahci0 [1] ahcich4: at channel 4 on ahci0 [1] ahcich5: at channel 5 on ahci0 [1] ahciem0: on ahci0 [1] tpm0: iomem 0xfed40000-0xfed44fff on acpi0 [1] tpm: WEC WPCT200 rev 0x46 [1] WARNING: Device "tpm" is Giant locked and may be deleted before FreeBSD 13.0. [1] orm0: at iomem 0xd1800-0xd27ff pnpid ORM0000 on isa0 [1] atkbdc0: at port 0x60,0x64 on isa0 [1] atkbd0: irq 1 on atkbdc0 [1] kbd0 at atkbd0 [1] atkbd0: [GIANT-LOCKED] [1] coretemp0: on cpu0 [1] est0: on cpu0 [1] Timecounters tick every 1.000 msec [1] hdacc0: at cad 0 on hdac0 [1] hdaa0: at nid 1 on hdacc0 [1] pcm4: at nid 4 on hdaa0 [1] pcm5: at nid 5 on hdaa0 [1] pcm6: at nid 6 on hdaa0 [1] pcm7: at nid 7 on hdaa0 [1] Trying to mount root from ufs:/dev/ada1p2 [rw]... [1] Root mount waiting for: usbus0 usbus1 usbus2 usbus3 CAM [1] WARNING: WITNESS option enabled, expect reduced performance. [1] ugen0.1: <0x1033 XHCI root HUB> at usbus0 [1] ugen2.1: at usbus2 [1] ugen1.1: <0x1912 XHCI root HUB> at usbus1 [1] uhub0 on usbus2 [1] uhub0: on usbus2 [1] uhub1 on usbus0 [1] uhub1: <0x1033 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0 [1] uhub2 on usbus1 [1] uhub2: <0x1912 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus1 [1] ugen3.1: at usbus3 [1] uhub3 on usbus3 [1] uhub3: on usbus3 [1] ses0 at ahciem0 bus 0 scbus6 target 0 lun 0 ses0: SEMB S-E-S 2.00 device ses0: SEMB SES Device [1] ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ACS-2 ATA SATA 3.x device ada0: Serial Number S1DBNSAD998260X ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes) ada0: Command Queueing enabled ada0: 238475MB (488397168 512 byte sectors) ada0: quirks=0x3<4K,NCQ_TRIM_BROKEN> [1] ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 ada1: ACS-2 ATA SATA 3.x device ada1: Serial Number 172910A024C1 ada1: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 512bytes) ada1: Command Queueing enabled ada1: 114473MB (234441648 512 byte sectors) [1] ses0: ada0 in 'Slot 00', SATA Slot: scbus0 target 0 [1] ses0: ada1 in 'Slot 01', SATA Slot: scbus1 target 0 [1] ada2 at ahcich5 bus 0 scbus5 target 0 lun 0 ada2: ACS-2 ATA SATA 3.x device ada2: Serial Number Z4Z7YY9Z ada2: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 512bytes) ada2: Command Queueing enabled ada2: 1907729MB (3907029168 512 byte sectors) ada2: quirks=0x1<4K> [1] ses0: (none) in 'Slot 03', SATA Slot: scbus3 target 0 [1] ses0: ada2 in 'Slot 05', SATA Slot: scbus5 target 0 [1] cd0 at ahcich3 bus 0 scbus3 target 0 lun 0 cd0: Removable CD-ROM SCSI device cd0: Serial Number MDDL002204WL cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed [1] uhub1: 4 ports with 4 removable, self powered [1] uhub2: 8 ports with 8 removable, self powered [2] uhub3: 2 ports with 2 removable, self powered [2] uhub0: 2 ports with 2 removable, self powered [2] Root mount waiting for: usbus2 usbus3 [2] ugen3.2: at usbus3 [2] uhub4 on uhub3 [2] uhub4: on usbus3 [3] ugen2.2: at usbus2 [3] uhub5 on uhub0 [3] uhub5: on usbus2 [3] Root mount waiting for: usbus2 usbus3 [3] uhub5: 6 ports with 6 removable, self powered [4] uhub4: 8 ports with 8 removable, self powered [4] ugen2.3: at usbus2 [4] ukbd0 on uhub5 [4] ukbd0: on usbus2 [4] kbd2 at ukbd0 [5] Root mount waiting for: usbus2 [5] ugen2.4: at usbus2 [5] ukbd1 on uhub5 [5] ukbd1: on usbus2 [5] kbd3 at ukbd1 [5] mountroot: waiting for device /dev/ada1p2... [6] lo0: link state changed to UP [10] em0: link state changed to UP [10] ichsmb0: port 0x3000-0x301f mem 0xeb424000-0xeb4240ff irq 18 at device 31.3 on pci0 [10] smbus0: on ichsmb0 [10] acpi_wmi0: on acpi0 [10] acpi_wmi0: cannot find EC device [10] uhid0 on uhub5 [10] uhid0: on usbus2 [10] uhid1 on uhub5 [10] uhid1: on usbus2 [10] uhid2 on uhub5 [10] uhid2: on usbus2 [10] uhid3 on uhub5 [10] uhid3: on usbus2 [10] ums0 on uhub5 [10] ums0: on usbus2 [10] ums0: 8 buttons and [XYZ] coordinates ID=0 [11] ipfw2 (+ipv6) initialized, divert loadable, nat loadable, default to deny, logging disabled [11] Security policy loaded: MAC/ntpd (mac_ntpd) [12] acquiring duplicate lock of same type: "os.lock_mtx" [12] 1st os.lock_mtx @ nvidia_os.c:900 [12] 2nd os.lock_mtx @ nvidia_os.c:900 [12] stack backtrace: [12] #0 0xffffffff80c80ce1 at witness_debugger+0x71 [12] #1 0xffffffff80bedc04 at __mtx_lock_flags+0x94 [12] #2 0xffffffff82e9f5fb at os_acquire_spinlock+0x1b [12] #3 0xffffffff82dad14c at _nv033412rm+0xc From owner-freebsd-current@freebsd.org Tue Dec 29 10:56:03 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 17A784B8A04 for ; Tue, 29 Dec 2020 10:56:03 +0000 (UTC) (envelope-from fischerking1905@yahoo.co.jp) Received: from nh505-vm12.bullet.mail.kks.yahoo.co.jp (nh505-vm12.bullet.mail.kks.yahoo.co.jp [183.79.57.114]) by mx1.freebsd.org (Postfix) with SMTP id 4D4rtm3yLlz3rP3 for ; Tue, 29 Dec 2020 10:55:59 +0000 (UTC) (envelope-from fischerking1905@yahoo.co.jp) Received: from [183.79.100.139] by nh505.bullet.mail.kks.yahoo.co.jp with NNFMP; 29 Dec 2020 10:55:56 -0000 Received: from [183.79.100.132] by t502.bullet.mail.kks.yahoo.co.jp with NNFMP; 29 Dec 2020 10:55:56 -0000 Received: from [127.0.0.1] by omp501.mail.kks.yahoo.co.jp with NNFMP; 29 Dec 2020 10:55:56 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 220999.87627.bm@omp501.mail.kks.yahoo.co.jp X-YMail-OSG: 2ALVUsAVM1nlOCT.yEKtmosafTZIAqnYqzSlF5zCk6PIhzdRwCyrDEDZpyxw9xJ JN0diCjzzvNY51qdEowhsneTtVrsK69GvB0hSG7W3AL_qc5X9LCXYorakFa6.nXLt6RTk6kXVa_8 sYWwL6pKnPOEdbpRNPkLfbvy9HDJ7qtP4JjGmwvwxCB7HDj6lhkucR._B7bi6SpyIxad7jeUCCpb Iqgqt.nHKZs0sb56sVX6u8yRxsjQdzVdEbBOdYmduH_xc5XK8nKdxsUOOK4LA_aSiGJ1kTQGrsLw pfmKTk8.9IqQcnIzhMRr4z0SJKoqS7jWmUzga3PIcGKYu_UsPiEbOP2wdxQvJxBOAW.USQQAORxx 1kiwCftpLF1Z0GaSjjtZTVVIMDgXCdm9z5QKF3gi8JVbOVavgSzA4KyEXwGtGRBkGIKpSAqH_Lvh BHUqskvVgfikMM5.ctIW4RRdFaM_xZSNsghdlxrWdc5S5kkdaQlkh1I3TS8wxQTUrG70o238kzTB _NwBTG3iOUp3_uut1diQhmb5f3yz2zxdUG9SwOu1nNRMEVEMl2QLkq5wzCVJBFwVF7vQ3Ft17XrN KNY4NCsTz_E1sHqzsACqErF2dTKfnB_prL0VO4480.GByH.CADCNb1kV0l2TaYT0q8vyeqSU5UUv 6kcwgr7JjL7DDJGIC3.CvQB21tZIAJ.4wAN6d3kLE.0XvtCYiKEeT8IxZ4Q09FJCgBOsYF08AXfW TZT1RXnJApCxA4O91JQxpsW.U3MaNpd3Na6TtH9Et7MQXU5FaZDS6g12wS_npUmfAcbD_zVu1mUF w_b_tCU.KdfYfnRKQd65vi4XlfOWuSbDSqExjQNI5u.vNTkVA0XwPJfSNuc8MfneEE2__A3m6U0a 9E.pBiwIdLMc9R4abERc8OSnlRFUxEpb4qoFGiaM0nQ-- Received: from jws701004.mail.kks.yahoo.co.jp by sendmailws503.mail.kks.yahoo.co.jp; Tue, 29 Dec 2020 19:55:55 +0000; 1609239355.699 Date: Tue, 29 Dec 2020 19:55:54 +0900 (JST) From: To: blackfoxx , "freebsd-current@freebsd.org" Message-ID: <2006214503.1056432.1609239354553.JavaMail.yahoo@mail.yahoo.co.jp> In-Reply-To: References: Subject: Re: Need some help with audio/sound (to get S/PDIF Toslink to work). MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4D4rtm3yLlz3rP3 X-Spamd-Bar: ++ X-Spamd-Result: default: False [2.23 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[yahoo.co.jp]; R_SPF_ALLOW(-0.20)[+ip4:183.79.0.0/16]; HFILTER_URL_ONELINE(2.50)[plain:0:1]; DKIM_TRACE(0.00)[yahoo.co.jp:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.co.jp,none]; RCPT_COUNT_TWO(0.00)[2]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[183.79.57.114:from]; FREEMAIL_ENVFROM(0.00)[yahoo.co.jp]; ASN(0.00)[asn:24572, ipnet:183.79.0.0/16, country:JP]; DWL_DNSWL_NONE(0.00)[yahoo.co.jp:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; RCVD_COUNT_FIVE(0.00)[5]; R_DKIM_ALLOW(-0.20)[yahoo.co.jp:s=yj20110701]; NEURAL_SPAM_SHORT(0.99)[0.989]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[183.79.57.114:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_NO_DN(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[183.79.57.114:from]; HFILTER_URL_ONLY(1.64)[0.74683544303797]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 29 Dec 2020 10:56:03 -0000 https://forums.freebsd.org/threads/console-player-and-s-pdif-toslink.63371/ From owner-freebsd-current@freebsd.org Tue Dec 29 11:44:30 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 10A504BA444 for ; Tue, 29 Dec 2020 11:44:30 +0000 (UTC) (envelope-from blackfoxx@online.de) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.131]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.kundenserver.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D4syh5YWgz3vd5 for ; Tue, 29 Dec 2020 11:44:28 +0000 (UTC) (envelope-from blackfoxx@online.de) Received: from [192.168.1.60] ([80.153.188.170]) by mrelayeu.kundenserver.de (mreue010 [212.227.15.167]) with ESMTPSA (Nemesis) id 1Mv3Ds-1k3cny27Zw-00r31t for ; Tue, 29 Dec 2020 12:44:26 +0100 Subject: Re: Need some help with audio/sound (to get S/PDIF Toslink to work). To: freebsd-current@freebsd.org References: <2006214503.1056432.1609239354553.JavaMail.yahoo@mail.yahoo.co.jp> From: blackfoxx Message-ID: Date: Tue, 29 Dec 2020 12:45:48 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:68.0) Gecko/20100101 Thunderbird/68.12.0 MIME-Version: 1.0 In-Reply-To: <2006214503.1056432.1609239354553.JavaMail.yahoo@mail.yahoo.co.jp> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: de-DE Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:HW7a6Sn3EAguSxsvsQ5nJcCQ0INm6BX76KX4yZjbqpKcT9nnysI HHopvSsUY2KasitTAHXPBIuRxMFjtRiFEt7LBsNbvi3u/3kBXzSV3sWO2DCHNaPUGc41dSW 5O6tvF5ji4d4Ktp4IcIqJDdNjcCGDmYWOdv+BsLEJgTramZCNefc6FTfT85KzccpERoeiMR SftmhDPc4m1ZPxF7NWdFQ== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:DMadG31maKM=:M5hd8Qo2aMGn3GcJxzGZuB WvkoODBgjhH4h1Aa9ZKO4e3+8WLri2vS/vwV97ndD4VQngnFuIdqTYFOd9V13tytjbgEIIzbl 6DRcAP0ypnSYd09mpQTQ2T6yPfmv+4qZWmmhRgu6rS/vbWQ1wN3xmGW2XUPzvenCK42v1bF3Y bR4d3PDvNnYg1ios9Lm+xScuw032QtuDjVtTW7EtIgntOgDIwjZxP6d4YhkIYzbAiAK20KwWS Yq82vwW9kiTG1hZJqClQYv8aePlfoPngCxWEWNxzgvVYiyrS0bZDhJ1WmTLVBA/ZsvjDIbsqg W0FQVsUamvmzbILQ7+n4GpFd7pT+znHddxzlA+I5JfN8N7VQ2tBlahxfayjtyR389l0JRyAao jHKVHUhwBg4SPCW6NWmmXuYDuH5n5gDE88tVbYwfU/VvDHw2b0i/8EWewDuKzbHJbAdiNptbP wi/GV8cinQ== X-Rspamd-Queue-Id: 4D4syh5YWgz3vd5 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.30 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[212.227.126.131:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:212.227.126.128/25]; 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]; SPAMHAUS_ZRD(0.00)[212.227.126.131:from:127.0.2.255]; ARC_NA(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_IN_DNSWL_NONE(0.00)[212.227.126.131:from]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DMARC_NA(0.00)[online.de]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-current]; RWL_MAILSPIKE_POSSIBLE(0.00)[212.227.126.131:from] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 29 Dec 2020 11:44:30 -0000 Thank you. I already read this thread while researching. Doesn't help me, because not a single "Digital" output/device appears in my FreeBSD 13.0-CURRENT System: pcm0: on emu10kx0 pcm0: pcm1: on emu10kx0 pcm2: on emu10kx0 pcm3: on emu10kx0 These 4 or 5 are just analog outputs/devices. Maybe the digital (S/PDIF, Toslink) issn't recognized by the system?! But I don't know how to "make" it recognized by FreeBSD. With Devuan (ALSA) and Win10 (Creative Driver) everything is working fine there. I also tried OSS, ALSA and PulseAudio with FreeBSD, but no chance to make it work. Am 29.12.2020 um 11:55 schrieb fischerking1905@yahoo.co.jp: > https://forums.freebsd.org/threads/console-player-and-s-pdif-toslink.63371/ > > _______________________________________________ > 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 Dec 29 12:15: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 1BF874BB8FD for ; Tue, 29 Dec 2020 12:15:06 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D4tf20Hclz4S86; Tue, 29 Dec 2020 12:15:06 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from venus.codepro.be (venus.codepro.be [5.9.86.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.codepro.be", Issuer "R3" (verified OK)) (Authenticated sender: kp) by smtp.freebsd.org (Postfix) with ESMTPSA id D871128B69; Tue, 29 Dec 2020 12:15:05 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: by venus.codepro.be (Postfix, authenticated sender kp) id 3DF834FF37; Tue, 29 Dec 2020 13:15:04 +0100 (CET) From: "Kristof Provost" To: monochrome Cc: freebsd-current@freebsd.org Subject: Re: git and the loss of revision numbers Date: Tue, 29 Dec 2020 13:15:03 +0100 X-Mailer: MailMate (1.13.2r5673) Message-ID: <84B2B085-97FD-4C63-96C5-0B65371060B7@FreeBSD.org> In-Reply-To: <8fb16182-e590-6bf0-747f-bc820dea1a3e@twcny.rr.com> References: <54116640-E6A1-4C53-9D7E-4384F942628E@ellael.org> <8ABAC674-89AA-47BE-996C-4DF6E7713F21@ellael.org> <53dd689b-2401-8e90-f332-50c60c549c2e@FreeBSD.org> <1d1e2003-0cc1-6e67-0ceb-f0fcba03f8f7@twcny.rr.com> <6a83684d-ee5b-5002-3553-7b383f02768c@nomadlogic.org> <8fb16182-e590-6bf0-747f-bc820dea1a3e@twcny.rr.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 29 Dec 2020 12:15:06 -0000 On 29 Dec 2020, at 4:33, monochrome wrote: > sry forgot details: > > source tree @ ead01bfe8 > > git -C /usr/src checkout gf20c0e331 > error: pathspec 'gf20c0e331' did not match any file(s) known to git > > what is the 'g' for? > That would have been a typo, I think. > git -C /usr/src checkout f20c0e331 > M sys/amd64/conf/GENERIC > HEAD is now at f20c0e331 caroot: drop $FreeBSD$ expansion from root > bundle > > yet I don't see any indication that anything changed, and now it wont > update at all: > If something went wrong there’d be error output. Git is *fast*, which can lead you to assume it’s not done anything when it has in fact done exactly what you asked. You should be on that commit now. > git -C /usr/src pull --ff-only > You are not currently on a branch. > Please specify which branch you want to merge with. > See git-pull(1) for details. > > git pull Yes, you can’t merge to a detached head. Return to your original branch (presumably git checkout main) and then pull. Regards, Kristof From owner-freebsd-current@freebsd.org Tue Dec 29 13:28:44 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 0C22A4BEDA3 for ; Tue, 29 Dec 2020 13:28:44 +0000 (UTC) (envelope-from monochrome@twcny.rr.com) Received: from p-impout005.msg.pkvw.co.charter.net (p-impout005aa.msg.pkvw.co.charter.net [47.43.26.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D4wGz1Qhtz4YtS for ; Tue, 29 Dec 2020 13:28:42 +0000 (UTC) (envelope-from monochrome@twcny.rr.com) Received: from [192.168.13.11] ([45.47.33.158]) by cmsmtp with ESMTP id uF3JkchoFiNLEuF3Jk5QZZ; Tue, 29 Dec 2020 13:28:41 +0000 X-Authority-Analysis: v=2.3 cv=QJYWuTDL c=1 sm=1 tr=0 a=VvwePSPmDFBOGFNvGtd2Cw==:117 a=VvwePSPmDFBOGFNvGtd2Cw==:17 a=IkcTkHD0fZMA:10 a=6I5d2MoRAAAA:8 a=veNgSRtZSUSFm_0Aq-8A:9 a=QEXdDO2ut3YA:10 a=IjZwj45LgO3ly-622nXo:22 Subject: Re: git and the loss of revision numbers To: freebsd-current@freebsd.org References: <54116640-E6A1-4C53-9D7E-4384F942628E@ellael.org> <8ABAC674-89AA-47BE-996C-4DF6E7713F21@ellael.org> <53dd689b-2401-8e90-f332-50c60c549c2e@FreeBSD.org> <1d1e2003-0cc1-6e67-0ceb-f0fcba03f8f7@twcny.rr.com> <6a83684d-ee5b-5002-3553-7b383f02768c@nomadlogic.org> <8fb16182-e590-6bf0-747f-bc820dea1a3e@twcny.rr.com> <84B2B085-97FD-4C63-96C5-0B65371060B7@FreeBSD.org> From: monochrome Message-ID: <755854ef-63bf-ad8f-f6a0-6af194e98bd6@twcny.rr.com> Date: Tue, 29 Dec 2020 08:28:40 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <84B2B085-97FD-4C63-96C5-0B65371060B7@FreeBSD.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfNWf+qWXTS/M07l/bKQfiNpiKZc/CjCSenH+h9cGv/IetpWW9Xz+C+DRzPymexLL78Xj9N3R0hV9Gb6a7+k46nEo6ZvpojrC5N6Xn5d7I8PRXPjnPjno bC2di7jjtVO6ierOdp4pk15Gq5/KQSdJ0739dXBxbbmhYJcdiMxGWKkYR/UHf35VRsG0nf9FzTWAQw== X-Rspamd-Queue-Id: 4D4wGz1Qhtz4YtS X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.30 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[45.47.33.158:received]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[47.43.26.136:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:47.43.26.0/24]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[rr.com]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[47.43.26.136:from:127.0.2.255]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:40294, ipnet:47.43.24.0/21, country:US]; MIME_TRACE(0.00)[0:+]; MAILMAN_DEST(0.00)[freebsd-current]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 29 Dec 2020 13:28:44 -0000 On 12/29/20 7:15 AM, Kristof Provost wrote: > On 29 Dec 2020, at 4:33, monochrome wrote: >> sry forgot details: >> >> source tree @ ead01bfe8 >> >> git -C /usr/src checkout gf20c0e331 >> error: pathspec 'gf20c0e331' did not match any file(s) known to git >> >> what is the 'g' for? >> > That would have been a typo, I think. > the g is also in the uname output: main-c421-gf20c0e331-dirty >> git -C /usr/src checkout f20c0e331 >> M       sys/amd64/conf/GENERIC >> HEAD is now at f20c0e331 caroot: drop $FreeBSD$ expansion from root >> bundle >> >> yet I don't see any indication that anything changed, and now it wont >> update at all: >> > If something went wrong there’d be error output. > Git is *fast*, which can lead you to assume it’s not done anything when > it has in fact done exactly what you asked. You should be on that commit > now. > that was the full output, and nothing showing that it changed/reverted any files, and the contents of /usr/src/.git/refs/heads/main is still ead01bfe8618e879b3b23c6cf9f026eadcc7d2b3 is there another place to find the current revision of the source? the point here is to revert to a previous known working state of the source tree exactly like svnlite update -rXXXXXX /usr/src used to do, and svn could then update from that point again with the same command used to do regular update: svnlite update /usr/src >> git -C /usr/src pull --ff-only >> You are not currently on a branch. >> Please specify which branch you want to merge with. >> See git-pull(1) for details. >> >>     git pull > > Yes, you can’t merge to a detached head. Return to your original branch > (presumably git checkout main) and then pull. > > Regards, > Kristof > _______________________________________________ > 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" the point is, there are only 4 commands we need to do this entire thing and it should be ironed out: 1. initially download the source tree 2. get the current local source tree revision 3. update the local source tree 4. revert local source tree to previous state thanks for your input! From owner-freebsd-current@freebsd.org Tue Dec 29 14:37: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 2879E4C1296 for ; Tue, 29 Dec 2020 14:37:55 +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 4D4xpp4l02z4f06 for ; Tue, 29 Dec 2020 14:37:54 +0000 (UTC) (envelope-from avg@FreeBSD.org) X-Originating-IP: 195.64.148.76 Received: from [192.168.0.24] (unknown [195.64.148.76]) (Authenticated sender: andriy.gapon@uabsd.com) by relay4-d.mail.gandi.net (Postfix) with ESMTPSA id 45D47E0009; Tue, 29 Dec 2020 14:37:51 +0000 (UTC) To: Pete Wright , monochrome , freebsd-current@freebsd.org References: <54116640-E6A1-4C53-9D7E-4384F942628E@ellael.org> <8ABAC674-89AA-47BE-996C-4DF6E7713F21@ellael.org> <53dd689b-2401-8e90-f332-50c60c549c2e@FreeBSD.org> <1d1e2003-0cc1-6e67-0ceb-f0fcba03f8f7@twcny.rr.com> <6a83684d-ee5b-5002-3553-7b383f02768c@nomadlogic.org> From: Andriy Gapon Subject: Re: git and the loss of revision numbers Message-ID: Date: Tue, 29 Dec 2020 16:37:49 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <6a83684d-ee5b-5002-3553-7b383f02768c@nomadlogic.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4D4xpp4l02z4f06 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.34 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, 29 Dec 2020 14:37:55 -0000 On 2020-12-29 02:56, Pete Wright wrote: > > On 12/28/20 4:38 PM, monochrome wrote: >> what would be the git command for reverting source to a previous >> version using these numbers? for example, with svn and old numbers: >> svnlite update -r367627 /usr/src >> > I will generally just checkout the short git hash like so in my local > checkout: > $ git checkout gb81783dc98e6 > > you can quickly get the hashes by running "git log" from your checkout. I think that git checkout is a wrong tool here. I personally would use git reset --hard . Note that that command would also revert any local uncommitted changes as well! My view of the difference between the commands: - checkout: stage[*] a change that would modify the current state of the branch to the selected commit's state - reset: change the current branch (its head) to point to the selected commit [*] by stage I mean modify the working copy and the index. That is, if after git checkout you would run git commit then you would commit a change that reverts the current branch to the selected point. -- Andriy From owner-freebsd-current@freebsd.org Tue Dec 29 15:11: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 3CE8C4C2550 for ; Tue, 29 Dec 2020 15:11:08 +0000 (UTC) (envelope-from monochrome@twcny.rr.com) Received: from p-impout009.msg.pkvw.co.charter.net (p-impout009aa.msg.pkvw.co.charter.net [47.43.26.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D4yY71T09z4hJj for ; Tue, 29 Dec 2020 15:11:06 +0000 (UTC) (envelope-from monochrome@twcny.rr.com) Received: from [192.168.13.11] ([45.47.33.158]) by cmsmtp with ESMTP id uGeOkC8BrgxBouGeOkS9kg; Tue, 29 Dec 2020 15:11:05 +0000 X-Authority-Analysis: v=2.3 cv=eddDgIMH c=1 sm=1 tr=0 a=VvwePSPmDFBOGFNvGtd2Cw==:117 a=VvwePSPmDFBOGFNvGtd2Cw==:17 a=IkcTkHD0fZMA:10 a=KUqz1aUFNtIYWFtFfdEA:9 a=QEXdDO2ut3YA:10 Subject: Re: git and the loss of revision numbers To: freebsd-current@freebsd.org References: <54116640-E6A1-4C53-9D7E-4384F942628E@ellael.org> <8ABAC674-89AA-47BE-996C-4DF6E7713F21@ellael.org> <53dd689b-2401-8e90-f332-50c60c549c2e@FreeBSD.org> <1d1e2003-0cc1-6e67-0ceb-f0fcba03f8f7@twcny.rr.com> <6a83684d-ee5b-5002-3553-7b383f02768c@nomadlogic.org> From: monochrome Message-ID: <7bfab675-ddb4-bf53-d818-d35667c74522@twcny.rr.com> Date: Tue, 29 Dec 2020 10:11:04 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfH5fecbTKWYJ11GifqKXVQ9ja4M8DDdvxlY9zGbvPzAnfrB3y2NnnhqaOEZ0B3LM12Z+KefaFXviJMbaN+RwJiv0SS4P4sK69hQBpVA4NOzHCufvtdTa 1WzvvPCsFD+l8wmmYLVmLMKC4AvmbqCU8WeFQNVVwxBl7SVlfeJbCl+Ft0p7tSGOfZ4+95NmYNi4RQ== X-Rspamd-Queue-Id: 4D4yY71T09z4hJj X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.30 / 15.00]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[45.47.33.158:received]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[47.43.26.140:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:47.43.26.0/24]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[rr.com]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[47.43.26.140:from:127.0.2.255]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_IN_DNSWL_NONE(0.00)[47.43.26.140:from]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:40294, ipnet:47.43.24.0/21, country:US]; MIME_TRACE(0.00)[0:+]; MAILMAN_DEST(0.00)[freebsd-current]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 29 Dec 2020 15:11:08 -0000 ok, this appears to be what I was looking for example: git reset --hard f20c0e331 then: git pull --ff-only is again able to update as normal I should point out also that this is from the point of view of any random person just building freebsd from source, not a developer, so there are no local changes. Though it does blow away changes to the conf file, that's a lesser issue to deal with. thanks! On 12/29/20 9:37 AM, Andriy Gapon wrote: > On 2020-12-29 02:56, Pete Wright wrote: >> >> On 12/28/20 4:38 PM, monochrome wrote: >>> what would be the git command for reverting source to a previous >>> version using these numbers? for example, with svn and old numbers: >>> svnlite update -r367627 /usr/src >>> >> I will generally just checkout the short git hash like so in my local >> checkout: >> $ git checkout gb81783dc98e6 >> >> you can quickly get the hashes by running "git log" from your checkout. > > I think that git checkout is a wrong tool here. > I personally would use git reset --hard . > Note that that command would also revert any local uncommitted changes > as well! > > My view of the difference between the commands: > - checkout: stage[*] a change that would modify the current state of the > branch to the selected commit's state > - reset: change the current branch (its head) to point to the selected > commit > > [*] by stage I mean modify the working copy and the index. > That is, if after git checkout you would run git commit then you would > commit a change that reverts the current branch to the selected point. > From owner-freebsd-current@freebsd.org Tue Dec 29 15:40: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 5CF754C2FF2 for ; Tue, 29 Dec 2020 15:40:16 +0000 (UTC) (envelope-from naddy@mips.inka.de) Received: from mail.inka.de (mail.inka.de [IPv6:2a04:c9c7:0:1073:217:a4ff:fe3b:e77c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4D4zBl4jhmz4kCx for ; Tue, 29 Dec 2020 15:40:15 +0000 (UTC) (envelope-from naddy@mips.inka.de) Received: from mips.inka.de (naddy@[127.0.0.1]) by mail.inka.de with uucp (rmailwrap 0.5) id 1kuH6U-005Aue-PP; Tue, 29 Dec 2020 16:40:06 +0100 Received: from lorvorc.mips.inka.de (localhost [127.0.0.1]) by lorvorc.mips.inka.de (8.16.1/8.16.1) with ESMTP id 0BTFa514030740; Tue, 29 Dec 2020 16:36:05 +0100 (CET) (envelope-from naddy@lorvorc.mips.inka.de) Received: (from naddy@localhost) by lorvorc.mips.inka.de (8.16.1/8.16.1/Submit) id 0BTFa5h9030739; Tue, 29 Dec 2020 16:36:05 +0100 (CET) (envelope-from naddy) Date: Tue, 29 Dec 2020 16:36:05 +0100 From: Christian Weisgerber To: monochrome Cc: freebsd-current@freebsd.org Subject: Re: git and the loss of revision numbers Message-ID: References: <54116640-E6A1-4C53-9D7E-4384F942628E@ellael.org> <8ABAC674-89AA-47BE-996C-4DF6E7713F21@ellael.org> <53dd689b-2401-8e90-f332-50c60c549c2e@FreeBSD.org> <1d1e2003-0cc1-6e67-0ceb-f0fcba03f8f7@twcny.rr.com> <6a83684d-ee5b-5002-3553-7b383f02768c@nomadlogic.org> <8fb16182-e590-6bf0-747f-bc820dea1a3e@twcny.rr.com> <84B2B085-97FD-4C63-96C5-0B65371060B7@FreeBSD.org> <755854ef-63bf-ad8f-f6a0-6af194e98bd6@twcny.rr.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <755854ef-63bf-ad8f-f6a0-6af194e98bd6@twcny.rr.com> X-Rspamd-Queue-Id: 4D4zBl4jhmz4kCx X-Spamd-Bar: / X-Spamd-Result: default: False [-0.82 / 15.00]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a04:c9c7:0:1073:217:a4ff:fe3b:e77c:from]; FREEFALL_USER(0.00)[naddy]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[inka.de]; AUTH_NA(1.00)[]; NEURAL_SPAM_SHORT(0.28)[0.284]; SPAMHAUS_ZRD(0.00)[2a04:c9c7:0:1073:217:a4ff:fe3b:e77c:from:127.0.2.255]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:202113, ipnet:2a04:c9c7::/32, country:DE]; RCVD_TLS_LAST(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 29 Dec 2020 15:40:16 -0000 monochrome: > the g is also in the uname output: > > main-c421-gf20c0e331-dirty It's the brand new format: -c-g[-dirty] https://cgit.freebsd.org/src/commit/sys/conf/newvers.sh?id=8d405efd73d3991fe1647f91a2b7c9989dd5f18f -- Christian "naddy" Weisgerber naddy@mips.inka.de From owner-freebsd-current@freebsd.org Tue Dec 29 17:38: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 7D8824C621F for ; Tue, 29 Dec 2020 17:38:34 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from relay11.mail.gandi.net (relay11.mail.gandi.net [217.70.178.231]) (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 4D51qG0PZ9z4rk3 for ; Tue, 29 Dec 2020 17:38:33 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from [192.168.0.24] (unknown [195.64.148.76]) (Authenticated sender: andriy.gapon@uabsd.com) by relay11.mail.gandi.net (Postfix) with ESMTPSA id 87DF9100005; Tue, 29 Dec 2020 17:38:30 +0000 (UTC) Subject: Re: git and the loss of revision numbers To: monochrome , freebsd-current@freebsd.org References: <54116640-E6A1-4C53-9D7E-4384F942628E@ellael.org> <8ABAC674-89AA-47BE-996C-4DF6E7713F21@ellael.org> <53dd689b-2401-8e90-f332-50c60c549c2e@FreeBSD.org> <1d1e2003-0cc1-6e67-0ceb-f0fcba03f8f7@twcny.rr.com> <6a83684d-ee5b-5002-3553-7b383f02768c@nomadlogic.org> <7bfab675-ddb4-bf53-d818-d35667c74522@twcny.rr.com> From: Andriy Gapon Message-ID: <0adec2d2-acfb-9a3f-da69-aff7915ea67d@FreeBSD.org> Date: Tue, 29 Dec 2020 19:38:27 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <7bfab675-ddb4-bf53-d818-d35667c74522@twcny.rr.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4D51qG0PZ9z4rk3 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.34 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, 29 Dec 2020 17:38:34 -0000 On 2020-12-29 17:11, monochrome wrote: > ok, this appears to be what I was looking for > > example: > git reset --hard f20c0e331 > then: > git pull --ff-only > is again able to update as normal > > I should point out also that this is from the point of view of any > random person just building freebsd from source, not a developer, so > there are no local changes. Though it does blow away changes to the conf > file, that's a lesser issue to deal with. git stash [save] and git stash pop can be used to try[*] to preserve minor local changes. [*] there can be merge conflicts after stash pop if the same file(s) are changed upstream as well. -- Andriy From owner-freebsd-current@freebsd.org Tue Dec 29 18:12: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 1A3214C723D for ; Tue, 29 Dec 2020 18:12:42 +0000 (UTC) (envelope-from madpilot@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D52Zf0Hf7z4vZ3; Tue, 29 Dec 2020 18:12:42 +0000 (UTC) (envelope-from madpilot@FreeBSD.org) Received: from marvin.madpilot.net (host-79-12-130-69.retail.telecomitalia.it [79.12.130.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: madpilot/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 8E29E2AD63; Tue, 29 Dec 2020 18:12:41 +0000 (UTC) (envelope-from madpilot@FreeBSD.org) Subject: Re: git and the loss of revision numbers To: Andriy Gapon , monochrome , freebsd-current@freebsd.org References: <54116640-E6A1-4C53-9D7E-4384F942628E@ellael.org> <8ABAC674-89AA-47BE-996C-4DF6E7713F21@ellael.org> <53dd689b-2401-8e90-f332-50c60c549c2e@FreeBSD.org> <1d1e2003-0cc1-6e67-0ceb-f0fcba03f8f7@twcny.rr.com> <6a83684d-ee5b-5002-3553-7b383f02768c@nomadlogic.org> <7bfab675-ddb4-bf53-d818-d35667c74522@twcny.rr.com> <0adec2d2-acfb-9a3f-da69-aff7915ea67d@FreeBSD.org> From: Guido Falsi Message-ID: Date: Tue, 29 Dec 2020 19:12:40 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <0adec2d2-acfb-9a3f-da69-aff7915ea67d@FreeBSD.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 29 Dec 2020 18:12:42 -0000 On 29/12/20 18:38, Andriy Gapon wrote: > On 2020-12-29 17:11, monochrome wrote: >> ok, this appears to be what I was looking for >> >> example: >> git reset --hard f20c0e331 >> then: >> git pull --ff-only >> is again able to update as normal >> >> I should point out also that this is from the point of view of any >> random person just building freebsd from source, not a developer, so >> there are no local changes. Though it does blow away changes to the conf >> file, that's a lesser issue to deal with. > > git stash [save] and git stash pop can be used to try[*] to preserve > minor local changes. > > [*] there can be merge conflicts after stash pop if the same file(s) are > changed upstream as well. > Anyone who already uses git knows this, probably, but for the sake of people who have no experience with it "git stash pop" behaviour can be startling(at least, it was for me when I first used it): after a "git stash pop" which causes conflicts git will set up to actaully create a commit in the branch with the resolved conflict, which (usually for me) is not what one really wants. I usually just do "git reset; git stash drop" in this case and then fix conflicts, to leave me with no extra commits, the changes in my checkout as I want them and no stashed ones (gt does not remove the stash until you commit the resolved changes, which, as I said is not what I want to do usually) I hope I clearly explained this, and if this was obvious to everyone, sorry for the noise! -- Guido Falsi From owner-freebsd-current@freebsd.org Tue Dec 29 19:26:40 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 6A3A84C8DA1 for ; Tue, 29 Dec 2020 19:26:40 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4D54D014Zpz3Hth; Tue, 29 Dec 2020 19:26:39 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 0BTJQWE6088608 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Tue, 29 Dec 2020 21:26:35 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 0BTJQWE6088608 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 0BTJQWBP088607; Tue, 29 Dec 2020 21:26:32 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 29 Dec 2020 21:26:32 +0200 From: Konstantin Belousov To: John Baldwin Cc: Mateusz Guzik , "freebsd-current@freebsd.org" Subject: Re: panic: Assertion pgrp->pg_jobc > 0 failed at kern_proc.c:816 Message-ID: References: <8f88c925-f12a-6a51-c2b3-c21c55de8dab@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on tom.home X-Rspamd-Queue-Id: 4D54D014Zpz3Hth X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 29 Dec 2020 19:26:40 -0000 On Mon, Dec 28, 2020 at 12:44:18PM -0800, John Baldwin wrote: > On 12/28/20 12:24 PM, John Baldwin wrote: > > I got this panic again today in a VM when quitting a gdb > > session after killing a child process via 'kill'. > > > > panic: Assertion pgrp->pg_jobc > 0 failed at /git/bhyve/sys/kern/kern_proc.c:816 > > cpuid = 1 > > time = 1609185862 > > KDB: stack backtrace: > > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00946547f0 > > vpanic() at vpanic+0x181/frame 0xfffffe0094654840 > > panic() at panic+0x43/frame 0xfffffe00946548a0 > > _refcount_update_saturated() at _refcount_update_saturated/frame 0xfffffe00946548e0 > > killjobc() at killjobc+0x6a6/frame 0xfffffe0094654940 > > exit1() at exit1+0x6af/frame 0xfffffe00946549b0 > > sys_sys_exit() at sys_sys_exit+0xd/frame 0xfffffe00946549c0 > > amd64_syscall() at amd64_syscall+0x12e/frame 0xfffffe0094654af0 > > fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfffffe0094654af0 > > --- syscall (1, FreeBSD ELF64, sys_sys_exit), rip = 0x8024c8f0a, rsp = 0x7fffffffe358, rbp = 0x7fffffffe370 --- > > KDB: enter: panic > > [ thread pid 44034 tid 102484 ] > > Stopped at kdb_enter+0x37: movq $0,0x10ab066(%rip) > > > > From what I can tell, the child process that was killed via 'kill' has > > not yet exited and is stuck in ptracestop() from fork(): > > > > (kgdb) where > > #0 sched_switch (td=0xfffffe0094001a00, flags=) at /git/bhyve/sys/kern/sched_ule.c:2147 > > #1 0xffffffff80bf4015 in mi_switch (flags=266) at /git/bhyve/sys/kern/kern_synch.c:542 > > #2 0xffffffff80bfeba5 in thread_suspend_switch (td=, p=) > > at /git/bhyve/sys/kern/kern_thread.c:1477 > > #3 0xffffffff80bef04b in ptracestop (td=0xfffffe0094001a00, sig=17, si=0x0) > > at /git/bhyve/sys/kern/kern_sig.c:2642 > > #4 0xffffffff80ba1a54 in fork_return (td=0xfffffe0094001a00, frame=0xfffffe0094671b00) > > at /git/bhyve/sys/kern/kern_fork.c:1106 > > #5 0xffffffff80ba18b0 in fork_exit (callout=0xffffffff80ba1950 , arg=0xfffffe0094001a00, > > frame=0xfffffe0094671b00) at /git/bhyve/sys/kern/kern_fork.c:1069 > > #6 > > #7 0x00000008007b71aa in ?? () > > > > kgdb can't find the panicking process due to the zombproc removal, so I will > > have to go work on kgdb to recover from that change. :( > > I've come up with a shorter reproducer (original was trying to debug a perl script > in OpenSSL's test suite). > > Compile this program: > > #include > #include > #include > #include > #include > #include > > int > main(void) > { > pid_t pid, wpid; > > pid = fork(); > if (pid == -1) > err(1, "fork"); > if (pid == 0) { > printf("I'm in the child\n"); > exit(1); > } > printf("I'm in the parent\n"); > wpid = waitpid(pid, NULL, 0); > if (wpid < 0) > err(1, "waitpid"); > > return (0); > } > > Then in gdb do the following: > > # gdb101 ./forktest > ... > (gdb) catch fork > Catchpoint 1 (fork) > (gdb) r > Starting program: /mnt/forktest/forktest > > Catchpoint 1 (forked process 830), _fork () at _fork.S:4 > 4 _fork.S: No such file or directory. > (gdb) kill > Kill the program being debugged? (y or n) y > [Inferior 1 (process 828) killed] > (gdb) quit > > https://reviews.freebsd.org/D27816 From owner-freebsd-current@freebsd.org Tue Dec 29 19:41: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 6A2764C91BA for ; Tue, 29 Dec 2020 19:41:37 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D54YF2NNyz3Jw2; Tue, 29 Dec 2020 19:41:37 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro.local (unknown [IPv6:2601:648:8681:1cb0:6d19:4439:be3e:85c7]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 2EF272C66D; Tue, 29 Dec 2020 19:41:36 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Subject: Re: git and the loss of revision numbers To: monochrome , freebsd-current@freebsd.org References: <54116640-E6A1-4C53-9D7E-4384F942628E@ellael.org> <8ABAC674-89AA-47BE-996C-4DF6E7713F21@ellael.org> <53dd689b-2401-8e90-f332-50c60c549c2e@FreeBSD.org> <1d1e2003-0cc1-6e67-0ceb-f0fcba03f8f7@twcny.rr.com> <6a83684d-ee5b-5002-3553-7b383f02768c@nomadlogic.org> <7bfab675-ddb4-bf53-d818-d35667c74522@twcny.rr.com> From: John Baldwin Autocrypt: addr=jhb@FreeBSD.org; keydata= mQGiBETQ+XcRBADMFybiq69u+fJRy/0wzqTNS8jFfWaBTs5/OfcV7wWezVmf9sgwn8TW0Dk0 c9MBl0pz+H01dA2ZSGZ5fXlmFIsee1WEzqeJzpiwd/pejPgSzXB9ijbLHZ2/E0jhGBcVy5Yo /Tw5+U/+laeYKu2xb0XPvM0zMNls1ah5OnP9a6Ql6wCgupaoMySb7DXm2LHD1Z9jTsHcAQMD /1jzh2BoHriy/Q2s4KzzjVp/mQO5DSm2z14BvbQRcXU48oAosHA1u3Wrov6LfPY+0U1tG47X 1BGfnQH+rNAaH0livoSBQ0IPI/8WfIW7ub4qV6HYwWKVqkDkqwcpmGNDbz3gfaDht6nsie5Z pcuCcul4M9CW7Md6zzyvktjnbz61BADGDCopfZC4of0Z3Ka0u8Wik6UJOuqShBt1WcFS8ya1 oB4rc4tXfSHyMF63aPUBMxHR5DXeH+EO2edoSwViDMqWk1jTnYza51rbGY+pebLQOVOxAY7k do5Ordl3wklBPMVEPWoZ61SdbcjhHVwaC5zfiskcxj5wwXd2E9qYlBqRg7QeSm9obiBCYWxk d2luIDxqaGJARnJlZUJTRC5vcmc+iGAEExECACAFAkTQ+awCGwMGCwkIBwMCBBUCCAMEFgID AQIeAQIXgAAKCRBy3lIGd+N/BI6RAJ9S97fvbME+3hxzE3JUyUZ6vTewDACdE1stFuSfqMvM jomvZdYxIYyTUpC5Ag0ERND5ghAIAPwsO0B7BL+bz8sLlLoQktGxXwXQfS5cInvL17Dsgnr3 1AKa94j9EnXQyPEj7u0d+LmEe6CGEGDh1OcGFTMVrof2ZzkSy4+FkZwMKJpTiqeaShMh+Goj XlwIMDxyADYvBIg3eN5YdFKaPQpfgSqhT+7El7w+wSZZD8pPQuLAnie5iz9C8iKy4/cMSOrH YUK/tO+Nhw8Jjlw94Ik0T80iEhI2t+XBVjwdfjbq3HrJ0ehqdBwukyeJRYKmbn298KOFQVHO EVbHA4rF/37jzaMadK43FgJ0SAhPPF5l4l89z5oPu0b/+5e2inA3b8J3iGZxywjM+Csq1tqz hltEc7Q+E08AAwUIAL+15XH8bPbjNJdVyg2CMl10JNW2wWg2Q6qdljeaRqeR6zFus7EZTwtX sNzs5bP8y51PSUDJbeiy2RNCNKWFMndM22TZnk3GNG45nQd4OwYK0RZVrikalmJY5Q6m7Z16 4yrZgIXFdKj2t8F+x613/SJW1lIr9/bDp4U9tw0V1g3l2dFtD3p3ZrQ3hpoDtoK70ioIAjjH aIXIAcm3FGZFXy503DOA0KaTWwvOVdYCFLm3zWuSOmrX/GsEc7ovasOWwjPn878qVjbUKWwx Q4QkF4OhUV9zPtf9tDSAZ3x7QSwoKbCoRCZ/xbyTUPyQ1VvNy/mYrBcYlzHodsaqUDjHuW+I SQQYEQIACQUCRND5ggIbDAAKCRBy3lIGd+N/BCO8AJ9j1dWVQWxw/YdTbEyrRKOY8YZNwwCf afMAg8QvmOWnHx3wl8WslCaXaE8= Message-ID: Date: Tue, 29 Dec 2020 11:41:34 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: <7bfab675-ddb4-bf53-d818-d35667c74522@twcny.rr.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 29 Dec 2020 19:41:37 -0000 On 12/29/20 7:11 AM, monochrome wrote: > ok, this appears to be what I was looking for > > example: > git reset --hard f20c0e331 > then: > git pull --ff-only > is again able to update as normal > > I should point out also that this is from the point of view of any > random person just building freebsd from source, not a developer, so > there are no local changes. Though it does blow away changes to the conf > file, that's a lesser issue to deal with. One other thing to consider is that if you are trying to track down a regression, you can use 'git bisect' to do this and it will do the binary search for you. In the case of searching for a regression, you will be better served by that tool than trying to use 'git reset --hard' directly. The other approach you can use to avoid having to look up hashes would be to create your own local tags each time you update. Then you can easily go back to that tag by name instead of having to look up the hash. -- John Baldwin From owner-freebsd-current@freebsd.org Tue Dec 29 21:05:03 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 A19C84CADF5 for ; Tue, 29 Dec 2020 21:05:03 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4D56PV4kNfz3Pbm; Tue, 29 Dec 2020 21:05:02 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: by sdaoden.eu (Postfix, from userid 1000) id E570016057; Tue, 29 Dec 2020 22:04:54 +0100 (CET) Date: Tue, 29 Dec 2020 22:04:54 +0100 From: Steffen Nurpmeso To: Brooks Davis , Thomas Mueller , freebsd-current@freebsd.org Subject: Re: HEADS UP: FreeBSD src repo transitioning to git this weekend Message-ID: <20201229210454.Lh4y_%steffen@sdaoden.eu> In-Reply-To: <20201229011939.GU31099@funkthat.com> References: <31ab8015-a0c4-af77-0ead-a17da0f88f1d@freebsd.org> <5fdc0b90.1c69fb81.866eb.8c29SMTPIN_ADDED_MISSING@mx.google.com> <20201218175241.GA72552@spindle.one-eyed-alien.net> <20201218182820.1P0tK%steffen@sdaoden.eu> <20201223023242.GG31099@funkthat.com> <20201223162417.v7Ce6%steffen@sdaoden.eu> <20201229011939.GU31099@funkthat.com> Mail-Followup-To: Brooks Davis , Thomas Mueller , freebsd-current@freebsd.org User-Agent: s-nail v14.9.20-107-gf02322df OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. X-Rspamd-Queue-Id: 4D56PV4kNfz3Pbm X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.29 / 15.00]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[217.144.132.164:from]; NEURAL_HAM_MEDIUM(-0.99)[-0.986]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[sdaoden.eu]; NEURAL_HAM_LONG(-1.00)[-1.000]; SPAMHAUS_ZRD(0.00)[217.144.132.164:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MID_CONTAINS_FROM(1.00)[]; FREEMAIL_TO(0.00)[freebsd.org,twc.com]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15987, ipnet:217.144.128.0/20, country:DE]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 29 Dec 2020 21:05:03 -0000 John-Mark Gurney wrote in <20201229011939.GU31099@funkthat.com>: |Steffen Nurpmeso wrote this message on Wed, Dec 23, 2020 at 17:24 +0100: |>|Then there's also the point that the repo is (looks like it) using |>|SHA-1 hashes, which are effectively broken, so depending upon them |>|to validate the tree is questionable anyways. |> |> git uses the hardened SHA-1 for sure, which is, as far as i know, |> at least safe against the known attack. |> I .. have not tracked this, but i think upgrading to SHA-256 is |> possible, once this will become standard. Just even more |> metadata, then. I have not looked into this, still in progress. | |A new attack came out earlier this year: |https://eprint.iacr.org/2020/014.pdf Impressive document. Not a mathematician here, but still. |>From the paper: |> In particular, chosen-prefix collisions can break signature schemes and |> handshake security in secure channel protocols (TLS, SSH), if generated |> extremely quickly. | |The previous attack in 2017 did not break SHA-1 enough to render it's |use by git vulnerable, but the writing was on the wall for SHA-1... | |I believe this new attack makes git's use a SHA-1 vulnerable... |The type/length prefix that prevented the previous attacks from |working is not effective against the new attack... | |Also, the cost of the attack is not great ($45k), considering the recent Ha. |SolarWinds supply chain attack, being able to smuggle a modified file |into a git repo, say an OS's build server, such that the tools don't |know the tree is modified is a real problem... SHA-256 arrives, if you look at the git history. Until then signing a git tag even with SHA-1 is better than being unsealed. This attack, well, interesting that FreeBSD with so many developers with ssh push hasn't been soiled more often. I am cautious regarding such, there is a tremendous amount of propaganda against Russia and China going on .. and then who tapped the cables, who has the budget, hmm. I have read one US national security alert report once, and all i could see was a supposed russian who logged into an open management console, and immediately logged out again (if the session was printed correctly). On some software where this login possibility was publicly announced as being a problem months before. (I read around once i read this report.) So given that the software would at least log such login attempts it could even have been seen as a kind reminder, whatever. Maybe not. Was it "national security alert"?, i think yes. Well. It is always easy to point with fingers at someone else. But as always, situation is horror. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From owner-freebsd-current@freebsd.org Wed Dec 30 00:46:24 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 729A04CFC35 for ; Wed, 30 Dec 2020 00:46:24 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D5CJv1t2tz3srY; Wed, 30 Dec 2020 00:46:22 +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 0BU0kL68098669 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 29 Dec 2020 16:46:21 -0800 (PST) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id 0BU0kKoV098664; Tue, 29 Dec 2020 16:46:20 -0800 (PST) (envelope-from jmg) Date: Tue, 29 Dec 2020 16:46:20 -0800 From: John-Mark Gurney To: Brooks Davis , Thomas Mueller , freebsd-current@freebsd.org Subject: Re: HEADS UP: FreeBSD src repo transitioning to git this weekend Message-ID: <20201230004620.GB31099@funkthat.com> Mail-Followup-To: Brooks Davis , Thomas Mueller , freebsd-current@freebsd.org References: <5fdc0b90.1c69fb81.866eb.8c29SMTPIN_ADDED_MISSING@mx.google.com> <20201218175241.GA72552@spindle.one-eyed-alien.net> <20201218182820.1P0tK%steffen@sdaoden.eu> <20201223023242.GG31099@funkthat.com> <20201223162417.v7Ce6%steffen@sdaoden.eu> <20201229011939.GU31099@funkthat.com> <20201229210454.Lh4y_%steffen@sdaoden.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201229210454.Lh4y_%steffen@sdaoden.eu> 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]); Tue, 29 Dec 2020 16:46:21 -0800 (PST) X-Rspamd-Queue-Id: 4D5CJv1t2tz3srY X-Spamd-Bar: - X-Spamd-Result: default: False [-1.80 / 15.00]; RCVD_TLS_ALL(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)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[funkthat.com]; RBL_DBL_DONT_QUERY_IPS(0.00)[208.87.223.18:from]; AUTH_NA(1.00)[]; SPAMHAUS_ZRD(0.00)[208.87.223.18:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; FREEMAIL_TO(0.00)[freebsd.org,twc.com]; 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.34 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, 30 Dec 2020 00:46:24 -0000 Steffen Nurpmeso wrote this message on Tue, Dec 29, 2020 at 22:04 +0100: > |SolarWinds supply chain attack, being able to smuggle a modified file > |into a git repo, say an OS's build server, such that the tools don't > |know the tree is modified is a real problem... > > SHA-256 arrives, if you look at the git history. Until then > signing a git tag even with SHA-1 is better than being unsealed. Actually, no it is not. It provides a false sense a security. SHA-1 should only be used as a checksum (detecting non-malicous corruption) now. There's a reason I stopped signing (and even removed the historical signatures) of the magnet links that I produce for FreeBSD. This is also why I expanded the snapaid tool to support releases, to make it extermely easy to verify signatures: https://www.funkthat.com/gitea/jmg/snapaid > This attack, well, interesting that FreeBSD with so many > developers with ssh push hasn't been soiled more often. I am And that is why it isn't a major problem yet, in that there are additional layers of security, both ssh and https that help ensure integrity of the repo in transit... > cautious regarding such, there is a tremendous amount of > propaganda against Russia and China going on .. and then who > tapped the cables, who has the budget, hmm. I have read one US > national security alert report once, and all i could see was I am well aware of this, and infact, the reason I've been pushing for better security like this IS because of the actions of the NSA... I used to get lunch on a weekly basis across the street from one of the early revealed NSA wiretap rooms. -- 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 Wed Dec 30 02:02: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 92AB84D2034 for ; Wed, 30 Dec 2020 02:02:59 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660084.outbound.protection.outlook.com [40.107.66.84]) (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 4D5F1G2cpCz4RfD; Wed, 30 Dec 2020 02:02:57 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VE8i6iENivko55EuQQ7NISFn9kdykLe6yipfmQzmlmXiNAMrqWh07ktnM05PKMF+AcT5ct8ZT7RpYPt6BFV0uYdLJ8L0tOEkHTbuiNAUc4QlUtZibB0xEEE1HybUlRWfhv8Rig5U76FQ/wS9WD+Y6K/ULTwUab9Fn81t4MaryxO/cz8+OKx6HGmwgAW79HL8P7fZABK5Ky/NYiXgiexKkgmmJIns9RFha/d1UIzfWTbLeoJ1eUpgRSikHGeBjzHKGYDIsMK3g2phRu1KeuwFvGQ2PqLOU5RHCwTibO9RLfBWzKDnj8l0EseMkf+lKByI12s8PiqoE4I1PuYdw+QVMw== 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=/DxHfNuiIq44PuuBNgSPtB2dhTK1F6FHtYOh0csf7+0=; b=YFm/aim0xrAZrdRRSm6NhLRaAtuSLI/ti3Yxi4kz6gTLzn0T90dnWHUksCJlEyyMxFOJylR1Ysz2CfI08kI+nAR0Iq0wr3XyMB89py5Xflhn4QJ27qtNuZDmCNupaOr/ELWzHbYUKZ5Tnso87PjJtKEeWiCfRrwb5CikQOeeV2VBhm+fO6ckrYIXZrMuYDNjCdPaKaArDzURWkf+4NrjfO1Q/6/PoJ/eldyhkrjBivEiXOY7f4bqKTdMn5a1uPHnH+MV2jEtLSB0eaikFUj5EE3JOYO5woCy40KvWjZNVpfnzQIy7odma6tjecmzFrf1aNyfjxAzQzrDrmwEUbfFQQ== 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 YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:19::29) by YQBPR0101MB1761.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:8::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3721.19; Wed, 30 Dec 2020 02:02:55 +0000 Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::3d86:c7f9:bc4c:40c0]) by YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::3d86:c7f9:bc4c:40c0%6]) with mapi id 15.20.3700.031; Wed, 30 Dec 2020 02:02:48 +0000 From: Rick Macklem To: "freebsd-current@freebsd.org" CC: Konstantin Belousov , Alan Somers , Kirk McKusick , Mark Johnston Subject: r367672 broke the NFS server Thread-Topic: r367672 broke the NFS server Thread-Index: AQHW3k3ynlL3lGhXRkC37zjbBa1PUA== Date: Wed, 30 Dec 2020 02:02:48 +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: db511264-9876-46ca-f9f5-08d8ac6701f6 x-ms-traffictypediagnostic: YQBPR0101MB1761: 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: CupEadtwdJGL6x+McsV9rHp5Pg9ypLd7Enqat9brt8lztd2FHVO2yKH9lGwe2cBZN8Lk/yNlen/LnMXrC5vFxEB0MXrhT6m5WKFEsiYQBrZYV6JTAea8jqMPDtKNxid54hpOnsiiy3iAXwkxpZjHmbqDIjwl+2Sl4Wot7eSA8EhvE3Lbs5jiuC02Rdqh8GJWjxHOnfE49sA2eZOlkuccQbAjDsXpn7Ply0RauSmdLHsy2tVzMsgzUW8nBO55RBWqfZPl0xjPwYVtdW+s6qiZYkfwEQOvy0J1zAjpVoODbAdUvFTEOC9RY9QvqPiqP6gM+33ypp8t6BFJKuvm4zbPzlTFoNbb0AaLwHNp3D4V4WTjH1QzQQ8YQ9OOAlXrdPAzdpG9I9BKQx+Us8Wkwp5UlQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(136003)(39850400004)(396003)(376002)(366004)(346002)(54906003)(5660300002)(52536014)(786003)(316002)(66446008)(64756008)(186003)(8936002)(6506007)(2906002)(91956017)(66476007)(66946007)(76116006)(7696005)(6916009)(86362001)(4744005)(26005)(66556008)(8676002)(33656002)(9686003)(55016002)(4326008)(71200400001)(478600001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?5tiyKx8BstCDi9/oQMrYQnPzI5Pv7oUxPY9Rb9dtzLok+09r/1TuqV9DSU?= =?iso-8859-1?Q?wBv45jgmdPRH5dJG12EgcKvU/8GmzZt7OGWclczvSkRh8vJcjjDdCtXoJC?= =?iso-8859-1?Q?jUKnyetJCidHxiFsvdlGLI0muf6im/BrKa4klUEycYsGpzZ9Uv1TIRf4dS?= =?iso-8859-1?Q?pOohpavxsTnDwIrLP3HgslHCGEEQ9fMNMEZmjIwGT5sQ+lniN6RsalasbR?= =?iso-8859-1?Q?nCjF4r8lPVoxw86jCceDVJwx8I5G8BHVY0CmBAJ92PMSrGEefv8tYCHmQO?= =?iso-8859-1?Q?3GYlPn4ZPwMAp0vuY16N1dbtlI2FvdH7zZisXKCXKk+yDZc7hO6Wiw3vpi?= =?iso-8859-1?Q?nC9rqkYINkuMTbM/I8eUCnjK9aL9zQbUt3r5JKh+OQVd8OVJlTUBYXrzRp?= =?iso-8859-1?Q?tTMMEthJmPv4SHhF9/OY76KCDWdMWXGAxSOxyTvxPmsLLPkbxsrCxJuA+3?= =?iso-8859-1?Q?GUFb7IK0Rw8dYQ/1L6NERmRwkokWEs5ojrraJglfcD1Cvk2s1mXIMXAGFn?= =?iso-8859-1?Q?NbIPo9Wba+5UwxmN/FywJspCNtjkonyiSI3X0gZ8IMjPcXqFPm8paS0aEJ?= =?iso-8859-1?Q?nDxxOtCCbpIPjs9U0bFoXDzzbRXV7URoUYrV09+NPErMjmBIUWmJ1c1sRg?= =?iso-8859-1?Q?F8az4Lm4Mhh6WKjr2AYVxfAJFFXM4PAE+7TVPodPxOyRE1idnNXOHcCPFl?= =?iso-8859-1?Q?iW5FE65LvFrAxDSp/XuZ2H1sCNmVw8Mn4w4ssDmPokN71vLRjzYPbCwgSu?= =?iso-8859-1?Q?AGPV0EyXZOWHVCyCFLFEuGB1bLk7Ixo2R1tF9Ko23fG2+WogXm3RTYiMhs?= =?iso-8859-1?Q?Msv+mWX0AB/Rx3LnAO1ncKM2q4q5ESH3LofUQeHjb2zDHsNBvFnxr6+0iv?= =?iso-8859-1?Q?3RZZf1bTOY2qc0Cv5WynakPInDgvGjk6Kx6vYcPxMVWfKe9lRtUpwv0Y5q?= =?iso-8859-1?Q?ZcPqcCt3sYbxNXzvVBffo2hpyi4SpPjPB5rGI/PqA4bdJJ/8WXdz5Gth46?= =?iso-8859-1?Q?A4a+bgIe+VqzjSBO8=3D?= 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: YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: db511264-9876-46ca-f9f5-08d8ac6701f6 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Dec 2020 02:02:48.6138 (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: WC2l+bNSacdy8LUV2afM9EiykaWgccLoTuASQKuPSMO/mCTz8iPy2v1BJFyO2pc7C2qbfhlmOMgGpM5b6Q7c0A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQBPR0101MB1761 X-Rspamd-Queue-Id: 4D5F1G2cpCz4RfD X-Spamd-Bar: ----- X-Spamd-Result: default: False [-6.00 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[uoguelph.ca:+]; DMARC_POLICY_ALLOW(-0.50)[uoguelph.ca,none]; NEURAL_HAM_SHORT(-1.00)[-0.999]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[40.107.66.84:from]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector1]; FREEFALL_USER(0.00)[rmacklem]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[40.107.66.84:from:127.0.2.255]; DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[40.107.66.84:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.66.84:from]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 30 Dec 2020 02:02:59 -0000 Hi,=0A= =0A= Post r367671...=0A= When multiple files are being created by an NFS client in the same=0A= directory, the VOP_CREATE()/ufs_create() can fail with ERELOOKUP.=0A= This results in a EIO return to the NFS client.=0A= --> This causes "nfsv4 client/server protocol prob err=3D10026"=0A= on the client for NFSv4.0 mounts.=0A= --> This explains why this error has been reported by=0A= several people lately, although it should "never happen".=0A= =0A= Unfortunately, for the NFS server, the Lookup call is done separately=0A= and it will not be easy to redo it, given the current NFS code structure.= =0A= =0A= Is there another way to deal with the problem r367672 was fixing that=0A= avoids ufs_create() returning ERELOOKUP?=0A= =0A= rick=0A= =0A= From owner-freebsd-current@freebsd.org Wed Dec 30 02:30: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 F14D54D1DD9; Wed, 30 Dec 2020 02:30:34 +0000 (UTC) (envelope-from neel@neelc.org) Received: from rainpuddle.neelc.org (rainpuddle.neelc.org [IPv6:2001:19f0:8001:fed:5400:2ff:fe73:c622]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4D5Fd54Hkcz4SQN; Wed, 30 Dec 2020 02:30:33 +0000 (UTC) (envelope-from neel@neelc.org) Received: from mail.neelc.org (rainpuddle.neelc.org [IPv6:2001:19f0:8001:fed:5400:2ff:fe73:c622]) by rainpuddle.neelc.org (Postfix) with ESMTPSA id D0C23EB48F; Tue, 29 Dec 2020 18:30:23 -0800 (PST) MIME-Version: 1.0 Date: Tue, 29 Dec 2020 18:30:23 -0800 From: Neel Chauhan To: freebsd-hackers@freebsd.org Cc: freebsd-current@freebsd.org Subject: Intel TigerLake NVMe vmd: Adding Support & Debugging a Patch User-Agent: Roundcube Webmail/1.4.9 Message-ID: X-Sender: neel@neelc.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4D5Fd54Hkcz4SQN X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[neel]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2001:19f0:8001:fed:5400:2ff:fe73:c622:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_SPF_ALLOW(-0.20)[+a]; SPAMHAUS_ZRD(0.00)[2001:19f0:8001:fed:5400:2ff:fe73:c622:from:127.0.2.255]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[neelc.org,none]; RCVD_COUNT_ONE(0.00)[1]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:20473, ipnet:2001:19f0:8000::/38, country:US]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current,freebsd-hackers]; ONCE_RECEIVED(0.10)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 30 Dec 2020 02:30:35 -0000 Hi freebsd-hackers@, CC'd freebsd-current@, I hope you all had a wonderful holiday season. I recently got a HP Spectre x360 13t-aw200 which is an Intel TigerLake-based laptop. It has the Intel "Evo" branding and an "Optane" SSD which I disabled (so I can get a "second" SSD). On the Spectre, the NVMe is not detected: https://imgur.com/a/ighTwHQ I don't know if it is HP or Intel, but the VMD IDs device id is 8086:9a0b. I'm guessing Intel since Dell laptops (XPS, Vostro) also have this device ID [1]. Sadly, NVMe RAID is forced on this laptop. I wrote a rough patch to add the device IDs, and the patch is below: --- a/sys/dev/vmd/vmd.c +++ b/sys/dev/vmd/vmd.c @@ -66,13 +66,20 @@ struct vmd_type { #define INTEL_VENDOR_ID 0x8086 #define INTEL_DEVICE_ID_VMD 0x201d #define INTEL_DEVICE_ID_VMD2 0x28c0 +#define INTEL_DEVICE_ID_VMD3 0x9a0b static struct vmd_type vmd_devs[] = { { INTEL_VENDOR_ID, INTEL_DEVICE_ID_VMD, "Intel Volume Management Device" }, { INTEL_VENDOR_ID, INTEL_DEVICE_ID_VMD2, "Intel Volume Management Device" }, + { INTEL_VENDOR_ID, INTEL_DEVICE_ID_VMD3, "Intel Volume Management Device" }, { 0, 0, NULL } However, I get a panic whenever I use this patch: https://imgur.com/a/XUQksOi Without this patch, I am able to boot fine but can't see the SSD or any nvd* devices beyond a "none" device in `pciconf -lv`. For those who know about PCI/ACPI subsystems, can you please tell me what's going wrong? I'm still debugging in the meanwhile, but am no expert on PCI/ACPI subsystems. I may know more than most PC builders or CS grads, but not really enough to do it full-time. The Spectre's SSD works fine with Windows 10 (obviously) and Linux (Fedora and Debian tested). Best, Neel Chauhan Sources: [1]: Linux probes: * Vostro: https://certification.ubuntu.com/hardware/202007-28047 * XPS: https://linux-hardware.org/?probe=ba53f6e513 From owner-freebsd-current@freebsd.org Wed Dec 30 04:44:10 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 EBB114D635E for ; Wed, 30 Dec 2020 04:44:10 +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 4D5JbF5JWXz4blc for ; Wed, 30 Dec 2020 04:44:08 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XWy4lZdK7KAoN18VrrcqRf2bz3tGqo16Btb8Fl7Sis82G6XczBKsZT0fcQbD/rhzOU92noWKt+hhHdX9ZNFwDXTSPQaXNAFJVvl4nFPp1BibkVkGuAYCsC74mL8vhPX7LDYCgpRy32v7XJQdUFXk8teICDOzHYi/1bPiWdBvA7cZMhy2YEiU3LuZdChx2+SXdEZxqtpAoZPwrX1Zic/Mi+/QJFR8pqA+FPibuxgyN4JPi17OHBSe1NGc8utvL7UX4csYdNxZS6LIj8HS2EXZJHja2yKFEDVOsyIS/uN3HgNeyaVNS/cbhrF9pd8DYsFdRoWvocln7maEI3IPG9SG4Q== 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=iBXpMxP8WXSwENjLrrj4h55CYGXcJTm+wgkbcJYva+w=; b=RF81C1lfaOOQNdowDPXTMnpQh6OBS4wnfoMwfDvxm3IfRmqLq0BK9OCWG6bA1WpDc/yyAPPx6tlhSpltpK0ywAdbWoD5LuOHIjR24o8pA5o4LKPfDxx4I84T6Caew3hxLyFO7vg2XuOBC8Gx0XLg5L2JW/Tln40l6pzMIwVBrOTZn39Sf1ha6U8hV1cLDz+aGWiDPnOro1ESVGRj0Wvexp0EnuhuVm5f/z93+Z5t5dAdryaVxhREbWP2FIgxYkqoiFSsihS7QYz8KoVmty9bh2EdtKUvDP1hjnkrcTWhZJg2Z5xHErkHaCmxPd2Fen9SkXI3ogqHElJo8DNGBPweBw== 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 YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:19::29) by YQBPR0101MB1569.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:f::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3700.28; Wed, 30 Dec 2020 04:44:06 +0000 Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::3d86:c7f9:bc4c:40c0]) by YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::3d86:c7f9:bc4c:40c0%6]) with mapi id 15.20.3700.031; Wed, 30 Dec 2020 04:44:06 +0000 From: Rick Macklem To: "freebsd-current@freebsd.org" Subject: if you are exporting UFS file systems via NFS on a post Nov. 15 system, there is a problem Thread-Topic: if you are exporting UFS file systems via NFS on a post Nov. 15 system, there is a problem Thread-Index: AQHW3mVnER74floyzUGFXxtbZ1HxTg== Date: Wed, 30 Dec 2020 04:44:06 +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: 25e5b643-e4df-4088-860f-08d8ac7d8a3e x-ms-traffictypediagnostic: YQBPR0101MB1569: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2449; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: jrQ2Mf7Q9NU7h7gA14Aeiuaom11/ecwJDYtG08lK65ZjbrQtJhELrKu4E913cZLteexMMvZxmNaM6ZHEusDLeEbSn3+6K+bxUA4z9ESxJDjI5ATO7K5ElvAg0j0HLQwuq9uzAXMQGRO7aASKrWIDlttZb9dm+481Oj00x3/RB/6NaeG+PQ9euCJUW/Kr5CXhY3qyhfzAXsMPkWu0MafDxLRCZbyF6Pz3Xu9I2SEaJdWZskBqm46x095EDGjR3uyX3NwTWbXyxD/Y+ZJ4Swi9E8vtQ0gIu0yutWK29GsIeLIXqHX9iM0YKjLLt8db+dCs0e+2g+VY3lWDQmVIBbo3hFw3PZNJxAV95kOj5gOdMncIomwL4dwjaSWGTYa0A2p4KiQxHn5TmUJh1ailhYLGKA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(346002)(366004)(39860400002)(396003)(136003)(376002)(33656002)(52536014)(478600001)(66446008)(6506007)(8936002)(71200400001)(558084003)(86362001)(7696005)(55016002)(66946007)(8676002)(316002)(91956017)(186003)(26005)(5660300002)(66556008)(6916009)(2906002)(76116006)(9686003)(64756008)(786003)(66476007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?jk5n51Pi8VeKfUFfzLAP52HJEeCIbC1x655IpKc3UZkaP01dPX0MpC+6GB?= =?iso-8859-1?Q?ytyJHtGgf8Ymjxhoa5rjhnMt1N2LIX4/f8+RyG167AVpQBN4NYJ0hAV23T?= =?iso-8859-1?Q?MNKSccZW13abm6ScLYTeBVFRNS1Np3vMvWTvxgDl3YaPodE8jPxBnanSrP?= =?iso-8859-1?Q?28f5rXNA6hdyjP0Vjb6bulHHJUWW1EbV3fEE32QLJPYirhT8+6s1pgFy9a?= =?iso-8859-1?Q?uBRisnsIbWWjuuWBIm45H+X9sdt3x6qcAzRpmxWDM4S2YvDzOtgma5Y7Q8?= =?iso-8859-1?Q?NGudRdNr2fyoyo/xA0iF0Gr1qIMM2vhhFZq+YyBxNKm7lPDO9G+95PU7AC?= =?iso-8859-1?Q?FoE9mBnsjQjmfplnC3/dTLEl72lfXM9T3AhDUXodpkRc2gsUTEkOD/ZkeW?= =?iso-8859-1?Q?ZdDDK8ajPcB63s2Iqmc1upbFeWNS9iv6ghdHY3BKQ9BVVg6+pzJ1HhE4Oq?= =?iso-8859-1?Q?ErKAmmxXeWxspPmlByh6NNL3JdWqh4FM2e7O+JXinqErhu/9/RaGxVVDmr?= =?iso-8859-1?Q?eTWqYAbB6rYggCRFcafyc2ywz0PalAV+FT8Y/mrAP8e7hyJTXO9+eHEK9h?= =?iso-8859-1?Q?loFbeIWk8N8OST7ASFFCI7mOvZdy+5Ptt+EoJjjLW+n5KUbDxlkqcoFu0r?= =?iso-8859-1?Q?azr5VoLmJ/rlOOiJ14l8y5B0EqoXLNzfniKmsFaGR/Uu3ANqxf8JwnRP7N?= =?iso-8859-1?Q?cdoE2LeuvqjnJpmo+4cn6hJlRP1UUGDimKSpUTVrYRYZLd/vw9vByfkaoY?= =?iso-8859-1?Q?Z8GZmrnw9r3wlg1RchtbAejBdSrOPFlHjhcZH9bgfaBswXeJxytFCRQ5HQ?= =?iso-8859-1?Q?IwMkiqKW6b6qNS83n/Zgtr7dP5tdUS5V3xyxZMtbkNKZTb3UHMUJE9L36q?= =?iso-8859-1?Q?1Yz75SrpzSRP8IPjBorfPtjwt1H+bQsgupMMOX+TaIv8waALCV1unfJBuL?= =?iso-8859-1?Q?9cTePTqma7yzyy00ziQjjS4kLuDs7bAYYAysBZ0gNYVkMEeha4xBVD3dNz?= =?iso-8859-1?Q?WovfOA4tJ/ju9ad4A=3D?= 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: YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 25e5b643-e4df-4088-860f-08d8ac7d8a3e X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Dec 2020 04:44:06.1838 (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: ADUdHBfLYCZQ2eD+sIC+LNJhvGK85zX+ZNE8VWgtRSK0c6qoQyzJFHnoKxpPpeTmtJSWZXNT203heHyRVRXN8A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQBPR0101MB1569 X-Rspamd-Queue-Id: 4D5JbF5JWXz4blc X-Spamd-Bar: ----- X-Spamd-Result: default: False [-6.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a01:111:f400:fe5c::615:from]; 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.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[2a01:111:f400:fe5c::615:from:127.0.2.255]; RCVD_COUNT_THREE(0.00)[3]; DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim]; DKIM_TRACE(0.00)[uoguelph.ca:+]; DMARC_POLICY_ALLOW(-0.50)[uoguelph.ca,none]; NEURAL_HAM_SHORT(-1.00)[-0.997]; 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.34 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, 30 Dec 2020 04:44:11 -0000 If you are exporting UFS file systems via NFS and your kernel is=0A= built from head/current sources newer than Nov. 15=0A= (r367672 or newer), the NFS service will be broken.=0A= =0A= The only workaround is to turn both SU and SU+j off for the=0A= exported file systems via tunefs.=0A= =0A= rick=0A= From owner-freebsd-current@freebsd.org Wed Dec 30 04:58:49 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 D1F9F4D6747 for ; Wed, 30 Dec 2020 04:58:49 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "ultimatedns.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D5Jw92Hkdz4cZ5; Wed, 30 Dec 2020 04:58:48 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.16.1/8.16.1) with ESMTP id 0BU4xMIo038547; Tue, 29 Dec 2020 20:59:29 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) MIME-Version: 1.0 Date: Tue, 29 Dec 2020 20:59:22 -0800 From: Chris To: Brooks Davis , Thomas Mueller , freebsd-current@freebsd.org Subject: Re: HEADS UP: FreeBSD src repo transitioning to git this weekend In-Reply-To: <20201230004620.GB31099@funkthat.com> References: <5fdc0b90.1c69fb81.866eb.8c29SMTPIN_ADDED_MISSING@mx.google.com> <20201218175241.GA72552@spindle.one-eyed-alien.net> <20201218182820.1P0tK%steffen@sdaoden.eu> <20201223023242.GG31099@funkthat.com> <20201223162417.v7Ce6%steffen@sdaoden.eu> <20201229011939.GU31099@funkthat.com> <20201229210454.Lh4y_%steffen@sdaoden.eu> <20201230004620.GB31099@funkthat.com> User-Agent: UDNSMS/17.0 Message-ID: <274d765e4a841b5d52239d2dae58175e@bsdforge.com> X-Sender: bsd-lists@bsdforge.com Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4D5Jw92Hkdz4cZ5 X-Spamd-Bar: / X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 30 Dec 2020 04:58:49 -0000 On 2020-12-29 16:46, John-Mark Gurney wrote: > Steffen Nurpmeso wrote this message on Tue, Dec 29, 2020 at 22:04 +0100: >> |SolarWinds supply chain attack, being able to smuggle a modified file >> |into a git repo, say an OS's build server, such that the tools don't >> |know the tree is modified is a real problem... >> >> SHA-256 arrives, if you look at the git history. Until then >> signing a git tag even with SHA-1 is better than being unsealed. > > Actually, no it is not. It provides a false sense a security. SHA-1 > should only be used as a checksum (detecting non-malicous corruption) > now. > > There's a reason I stopped signing (and even removed the historical > signatures) of the magnet links that I produce for FreeBSD. > > This is also why I expanded the snapaid tool to support releases, to > make it extermely easy to verify signatures: > https://www.funkthat.com/gitea/jmg/snapaid > >> This attack, well, interesting that FreeBSD with so many >> developers with ssh push hasn't been soiled more often. I am > > And that is why it isn't a major problem yet, in that there are > additional layers of security, both ssh and https that help > ensure integrity of the repo in transit... > >> cautious regarding such, there is a tremendous amount of >> propaganda against Russia and China going on .. and then who >> tapped the cables, who has the budget, hmm. I have read one US >> national security alert report once, and all i could see was > > I am well aware of this, and infact, the reason I've been pushing > for better security like this IS because of the actions of the NSA... > I used to get lunch on a weekly basis across the street from one > of the early revealed NSA wiretap rooms. OK I've been pondering this since last night. If this is a reasonable concern, and given all that's already gone into coercing git into something FreeBSD friendly. Is it reasonable to consider putting all that effort that's already been excreted, and what would need to be done. To cobble up a FreeBSD version? [tongue-in-cheek] fuk-git -- FreeBSDUsersCare-git. Sorry. It's a strain. But I needed that acronym. Seriously tho. It wouldn't be that hard to provide sha384(1) at a minimum. Better; hmac-sha384, or any of a number of other digests. I'm just thinking that if everyone pitched in, what with all the other work that's already been done. It'd all get done on a timeline that wouldn't leave the FreeBSD repo unsafe. Mind you; much of this is all conceptual. But I just thought (hoped) it might be worth while. --Chris From owner-freebsd-current@freebsd.org Wed Dec 30 05:07:54 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 4FA494D694A for ; Wed, 30 Dec 2020 05:07:54 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "ultimatedns.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D5K6f0FQyz4dBG; Wed, 30 Dec 2020 05:07:53 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.16.1/8.16.1) with ESMTP id 0BU58Rgb099796; Tue, 29 Dec 2020 21:08:33 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) MIME-Version: 1.0 Date: Tue, 29 Dec 2020 21:08:27 -0800 From: Chris To: Brooks Davis , Thomas Mueller , freebsd-current@freebsd.org Subject: Re: HEADS UP: FreeBSD src repo transitioning to git this weekend In-Reply-To: <274d765e4a841b5d52239d2dae58175e@bsdforge.com> References: <5fdc0b90.1c69fb81.866eb.8c29SMTPIN_ADDED_MISSING@mx.google.com> <20201218175241.GA72552@spindle.one-eyed-alien.net> <20201218182820.1P0tK%steffen@sdaoden.eu> <20201223023242.GG31099@funkthat.com> <20201223162417.v7Ce6%steffen@sdaoden.eu> <20201229011939.GU31099@funkthat.com> <20201229210454.Lh4y_%steffen@sdaoden.eu> <20201230004620.GB31099@funkthat.com> <274d765e4a841b5d52239d2dae58175e@bsdforge.com> User-Agent: UDNSMS/17.0 Message-ID: <763bf958855f8eb181dfa5d40568a008@bsdforge.com> X-Sender: bsd-lists@bsdforge.com Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4D5K6f0FQyz4dBG X-Spamd-Bar: / X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 30 Dec 2020 05:07:54 -0000 On 2020-12-29 20:59, Chris wrote: > On 2020-12-29 16:46, John-Mark Gurney wrote: >> Steffen Nurpmeso wrote this message on Tue, Dec 29, 2020 at 22:04 +0100: >>> |SolarWinds supply chain attack, being able to smuggle a modified file >>> |into a git repo, say an OS's build server, such that the tools don't >>> |know the tree is modified is a real problem... >>> >>> SHA-256 arrives, if you look at the git history. Until then >>> signing a git tag even with SHA-1 is better than being unsealed. >> >> Actually, no it is not. It provides a false sense a security. SHA-1 >> should only be used as a checksum (detecting non-malicous corruption) >> now. >> >> There's a reason I stopped signing (and even removed the historical >> signatures) of the magnet links that I produce for FreeBSD. >> >> This is also why I expanded the snapaid tool to support releases, to >> make it extermely easy to verify signatures: >> https://www.funkthat.com/gitea/jmg/snapaid >> >>> This attack, well, interesting that FreeBSD with so many >>> developers with ssh push hasn't been soiled more often. I am >> >> And that is why it isn't a major problem yet, in that there are >> additional layers of security, both ssh and https that help >> ensure integrity of the repo in transit... >> >>> cautious regarding such, there is a tremendous amount of >>> propaganda against Russia and China going on .. and then who >>> tapped the cables, who has the budget, hmm. I have read one US >>> national security alert report once, and all i could see was >> >> I am well aware of this, and infact, the reason I've been pushing >> for better security like this IS because of the actions of the NSA... >> I used to get lunch on a weekly basis across the street from one >> of the early revealed NSA wiretap rooms. > OK I've been pondering this since last night. If this is a reasonable > concern, and given all that's already gone into coercing git into > something FreeBSD friendly. Is it reasonable to consider putting all > that effort that's already been excreted, and what would need to be > done. To cobble up a FreeBSD version? [tongue-in-cheek] > fuk-git -- FreeBSDUsersCare-git. Sorry. It's a strain. But I needed face-palm; that was: fuc-git. A failed attempt at wit. :-( the rest holds true. > that acronym. > Seriously tho. It wouldn't be that hard to provide sha384(1) at a minimum. > Better; hmac-sha384, or any of a number of other digests. I'm just > thinking that if everyone pitched in, what with all the other work > that's already been done. It'd all get done on a timeline that wouldn't > leave the FreeBSD repo unsafe. > Mind you; much of this is all conceptual. But I just thought (hoped) it > might be worth while. > > --Chris > _______________________________________________ > 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 Wed Dec 30 05:55:33 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 0837E4D7741 for ; Wed, 30 Dec 2020 05:55:33 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D5L9b55Vqz4g0V for ; Wed, 30 Dec 2020 05:55:31 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: by mail-ed1-x52c.google.com with SMTP id i24so14465007edj.8 for ; Tue, 29 Dec 2020 21:55:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=LvkJTYaI/KWbulIRlqTPG9MOTa3HiwkaWrTwvO1+ijg=; b=RX+Qv0gfxBzKEe/SMwAm4VuiTQVBipjYun+MonRNBJ2ZU6VmcNsGvQG/2AO+XWLD7w RV95j1AMJuYXNRF41ddxb2zVTig+fuHzfoSUziZD1zeK5mf/6vcdwjVpV4FSkop4g30i /1ZluEBfVEISXY9Tpd6BetQVQrvmQgcTnYBQrPSdP8Z7c1y4jD5fp2Zi4BzCWgKYDeuL CmpvGxAZmzsDF3lup4pm1y3MYEcCW1DcRswZvs4v7RV5GEc1ig1SNSVfmLw0XLBTwJPy XLNdrKbc4UVnePzAOutWwLhfTNdO0XB4+05g+CydAdTkvVL/6tjanH/mgRcyFzIeOD8x Eydw== X-Gm-Message-State: AOAM531VSa1/9U9P87yZdrMoOVx5l+ISHSvjpEWP3Y+6xu4sfaa3qQ36 gMv9bVq+EuJnes9F9MPisrPBqylamkN2nRGQL2hbqReWdV9Hgg== X-Google-Smtp-Source: ABdhPJyTqD/VBMxhLMXkm+acav3NBlqo8govqEw+5PttFNvwfGYKJExwLKtTBL0Y2d2kXT2ARCV31kVoqvQei9fbbPw= X-Received: by 2002:a05:6402:7d7:: with SMTP id u23mr48380184edy.325.1609307729641; Tue, 29 Dec 2020 21:55:29 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a54:3d8d:0:0:0:0:0 with HTTP; Tue, 29 Dec 2020 21:55:29 -0800 (PST) In-Reply-To: <20201230004620.GB31099@funkthat.com> References: <5fdc0b90.1c69fb81.866eb.8c29SMTPIN_ADDED_MISSING@mx.google.com> <20201218175241.GA72552@spindle.one-eyed-alien.net> <20201218182820.1P0tK%steffen@sdaoden.eu> <20201223023242.GG31099@funkthat.com> <20201223162417.v7Ce6%steffen@sdaoden.eu> <20201229011939.GU31099@funkthat.com> <20201229210454.Lh4y_%steffen@sdaoden.eu> <20201230004620.GB31099@funkthat.com> From: grarpamp Date: Wed, 30 Dec 2020 00:55:29 -0500 Message-ID: Subject: Re: HEADS UP: FreeBSD src repo transitioning to git this weekend To: freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4D5L9b55Vqz4g0V X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a00:1450:4864:20::52c:from]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[2a00:1450:4864:20::52c:from:127.0.2.255]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52c: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.34 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, 30 Dec 2020 05:55:33 -0000 >> SHA-256 arrives, if you look at the git history. > git's SHA-256 [...] requiring a super new git version to even test it out. It's "in" current release 2.30.0 and before, duly caveated as experimental and not fully featured yet... git-init(1) --object-format= Specify the given object format (hash algorithm) for the repository. The valid values are sha1 and (if enabled) sha256. sha1 is the default. > continue to test how well it works and monitor the > ecosystem for a transition in a few years when it is robust.. Sure, though perhaps freebsd may then find to enjoy a more middle lead, ahead than the rather later move of svn->git, and being already git it will be far less work. There should be some freebsd press release when the current git deploy is all done, as new people from outside will like to know last big OS is on git and then use it more too. > signatures of the magnet links Signing torrent.asc, with stronger or even same hash as BT protocol, still serve purpose of authenticate torrent file back to a signer to the degree therein, caveat their platform security, caveat sha-1 inside torrent still being abuseable by third party, caveat etc. With no torrent.asc there is nothing directly saying the torrent file / infohash itself went through freebsd project. Whether torrent or git or else, there can be useable scope and case for such "stronger over weaker" constructions. gpg offers better hash algos than sha-1 these days, all users should look into configuring and using it, same goes for abandoning the old [a]symmetric algos and weaker keys, made with old weak /dev/random, etc. One cannot sign or verify anything without knowing gpg first :) And even port called "age" is of simple utility too. From owner-freebsd-current@freebsd.org Wed Dec 30 07:04:07 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 167894B903E for ; Wed, 30 Dec 2020 07:04:07 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D5Mhj5sDQz4kLF for ; Wed, 30 Dec 2020 07:04:05 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from hermann.fritz.box ([89.12.11.0]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MFsUp-1kncR10Qed-00HMtT for ; Wed, 30 Dec 2020 08:04:04 +0100 Date: Wed, 30 Dec 2020 08:04:03 +0100 From: "Hartmann, O." To: FreeBSD CURRENT Subject: # Fssh_packet_write_wait: Connection to 77.183.250.3 port 22: Broken pipe Message-ID: <20201230080403.5474da7c@hermann.fritz.box> Organization: walstatt.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/DiADLrU_uOTwhhtOoPsJdUZ"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Provags-ID: V03:K1:F6EearWGfayzhzZMoHoS5/o9H8jTsuzEVS3xkAh/3USOmGkQHKy 2RnsamF+QS5Zf3nWU0Oeng/RkrYgiMGx8HtUQ4uQ3xRe+YyWSJlHZ+w1quqCLl30u/i4/po UMyFtO219eY8fZV2HBMmZ95nCWvBNi1A4U2CYKQZOa6SSqRN+Yho9yG4SrcCaDlxWkJ6Jh9 EUcj/5R3M89Pjpq/DUEmA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:tL16DwLGtvE=:CxUdOkXjw260kxMFDyevDz ZUwpQffg8WPJNEGDL2YcS+uRYTgsnof4KzaXvuQpQPEA3slOdb9UvIpUYqzsOpPe2PGqQgcma OrflJITjX0Nq6ldRSHcirCOT0KdAYZkqeWvnMnY4RnZspDeJ9CkcQKLCCaSA+3gPEq/FqUFV2 OyoOnfvOt8NOI+CfgIbGefkA282hCZ0e2abIm7jzfmR+3rtaLbucQtHG/3ezkhfBaNuUuKGdo j8j2lteZ5ey+IDhpkl0v1uAt/Z37OQqMhSHHm2lpbChwKMxhjTf2gFmsffzprSTydT3G93/9C r6CZWqEEVjlJM5BC0OyayDI00mfEEOLuly4+0EVjcJdqeBMyQ4ovQHvagbGzmHz0km2d42n43 H5SQSeUpf2nu90T31Zp5Mqpe89pPV+YXrJfTkP89AQA6GdhFbJjwEdBsnbquL5tHY2NTeX9qH Dz6hHSb/xVrr6oe+rTz6gf4v/Y9w/MceQmPO3GDQjaHHqwKhiSAZkJIbY7HHGkJtN2vmntzdG eDptQd9h1y6HR6/SsnH9j/3YGt1rc+YVrllHa0DV15jaJN6I5x2uOvoyRta0HM4v+uzgo+m0k HQYp2x5GdsnEpkVTJE2+sn7xdevOiaJGGEx4K1SDk3JJ04EqiGiqjF3yVCalEuuXdIlrdPoNM erU2IjjRpmQwSVRtujKL6LBhCjAkdVyk/jDQI/ZBqORY9cRfQZ6X1zAvjERxfyJYKhshaKzUd J992o5wiwn2HJ+YMwPO/903Wiqej2PAEk8WMdtB1I3OhhER3xeavSZ2mNKaGiAYAxvUq2YNdS IGUWiEV5J2qEi+X+a8DYmpsgqVzRzQkba1ezlmiegtPVxOF3GTnSr7J3BM3kIkGa1dMwlOVPW 7x5MFnK2889A+b/a3d0A== X-Rspamd-Queue-Id: 4D5Mhj5sDQz4kLF X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.14 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_ORG_HEADER(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmx.net:+]; NEURAL_HAM_SHORT(-0.64)[-0.640]; RECEIVED_SPAMHAUS_PBL(0.00)[89.12.11.0:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RBL_DBL_DONT_QUERY_IPS(0.00)[212.227.17.20:from]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE]; RCVD_IN_DNSWL_LOW(-0.10)[212.227.17.20:from]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmx.net:s=badeba3b8450]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[walstatt.org]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[212.227.17.20:from:127.0.2.255]; R_SPF_NA(0.00)[no SPF record]; RWL_MAILSPIKE_POSSIBLE(0.00)[212.227.17.20: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.34 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, 30 Dec 2020 07:04:07 -0000 --Sig_/DiADLrU_uOTwhhtOoPsJdUZ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On recent 12-STABLE, 12.1-RELENG and 12.2-RELENG I face a very nasty proble= m which occured a while ago after it seemed to have vanished for a while: running s= sh in a xterm on FreeBSD boxes as mentioned at the beginning ends up very rapidly in a lo= st connection with # Fssh_packet_write_wait: Connection to XXX.XXX.XXX.XXX port 22: Broken pipe The backend is in most cases a CURRENT, 12.1-RELENG or 12.2-RELENG or 12-ST= ABLE server. A couple of months ago we moved from 11.3-RELENG to 12.1-RELENG (server side,= clients were always 13-CURRENT or 12-STABLE). With FreeBSD 11 as the backend, those brok= en pipes occured, but not that frequent and rapid as it is the fact now.=20 The "problem" can be mitigated somehow: running top or using the console pr= events the broken pipe fault for a while, but it still occurs. Running "screen" (port sysutils/screen) does extend the usability of the console for a significant= timespan, but the broken pipe also occurs randomly, but it takes a significant time to oc= cur. All systems mentioned above are highly customized, so I used the chance of = another, more "generic" scenario to test. The backend is a most recent Xigmanas machine (= running Hardened FreeBSD 12, latest official issue, its based on FBSD 12.1). Access= ing clients are recent GhostBSD or FreeBSD 12.2-RELENG, utilizing Remmina (port sysutil= s/remmina). It doesn't matter whether I take the ports from our local poudriere driven rep= ository or from one of the official ones. SSH via Remmina dies the same death as it do= es on all customized boxes. And those failing scenarios are occur in all kind of netw= orks, home-ISP-lab/work, lab's network, home's network with foreign, Linux based = CPE or other vendor's CPE. My conclusion is: either there is a serious problem with FreeBSD since 12, = or there is a config issue I'm not aware of, even with "vanilla" installations from offic= ial repository running unchanged. Kind regards, oh --Sig_/DiADLrU_uOTwhhtOoPsJdUZ Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQSy8IBxAPDkqVBaTJ44N1ZZPba5RwUCX+wmYwAKCRA4N1ZZPba5 R3+vAP9dBTPFgp/dBE9pWSKqaRupoIwOrI+IjwxmETthoQpGqQEAk/Io4jDycZpb yr54Ths7aMLmOobdxrK/isLyB8BzZwM= =Aeg4 -----END PGP SIGNATURE----- --Sig_/DiADLrU_uOTwhhtOoPsJdUZ-- From owner-freebsd-current@freebsd.org Wed Dec 30 12:53: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 0AB674C28AE for ; Wed, 30 Dec 2020 12:53:19 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4D5WRf4gR4z3MmH; Wed, 30 Dec 2020 12:53:18 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 0BUCrAkx036984 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 30 Dec 2020 14:53:13 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 0BUCrAkx036984 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 0BUCr9gX036983; Wed, 30 Dec 2020 14:53:09 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 30 Dec 2020 14:53:09 +0200 From: Konstantin Belousov To: Rick Macklem Cc: "freebsd-current@freebsd.org" , Alan Somers , Kirk McKusick , Mark Johnston Subject: Re: r367672 broke the NFS server Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on tom.home X-Rspamd-Queue-Id: 4D5WRf4gR4z3MmH X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 30 Dec 2020 12:53:19 -0000 On Wed, Dec 30, 2020 at 02:02:48AM +0000, Rick Macklem wrote: > Hi, > > Post r367671... > When multiple files are being created by an NFS client in the same > directory, the VOP_CREATE()/ufs_create() can fail with ERELOOKUP. > This results in a EIO return to the NFS client. > --> This causes "nfsv4 client/server protocol prob err=10026" > on the client for NFSv4.0 mounts. > --> This explains why this error has been reported by > several people lately, although it should "never happen". > > Unfortunately, for the NFS server, the Lookup call is done separately > and it will not be easy to redo it, given the current NFS code structure. > > Is there another way to deal with the problem r367672 was fixing that > avoids ufs_create() returning ERELOOKUP? Idea of the change is to restart the syscall at top level. So for NFS server the right approach is to not send a response and also to not free the request mbuf chain, but to restart processing. I am sorry I forgot about NFS server when designing this fix, the only mild excuse I can provide is that the change was quite complicated as is. I will start looking at the fix. From owner-freebsd-current@freebsd.org Wed Dec 30 13:14:54 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 8A0704C30E3 for ; Wed, 30 Dec 2020 13:14:54 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D5WwY3FtDz3NPQ for ; Wed, 30 Dec 2020 13:14:52 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from hermann.fritz.box ([89.12.11.0]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1Mxm3Q-1k5Ulb3Yh4-00zICq; Wed, 30 Dec 2020 14:14:49 +0100 Date: Wed, 30 Dec 2020 14:14:48 +0100 From: "Hartmann, O." To: Michael Tuexen Cc: FreeBSD CURRENT Subject: Re: # Fssh_packet_write_wait: Connection to 77.183.250.3 port 22: Broken pipe Message-ID: <20201230141448.48871cc5@hermann.fritz.box> In-Reply-To: References: <20201230080403.5474da7c@hermann.fritz.box> Organization: walstatt.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/8tXX7vAxhlkt+dhYppWM_C6"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Provags-ID: V03:K1:r3Fmp7VevJ5VxnsYwTvCbqnh8DAcvQJzGXOQY1mxX+VWi0m5sWO b985Ilcu6aFE42fxpFfl/YRXFsoeGZIV7ObTqKMF8TNIGuFvTZrG0yeUy8fgMlAuPcxKkH7 ubY282pDbUtF2KksW4J4GhC/lJefpinnhVdDwrTbTNPAG4NtP1Xt9pfMg8dH6K7MgvZOjal pIgY4IMXqd+BFosjL3uKg== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:PyTAG3DIbqA=:IYHqfeLcZiRV55eZ/4qpww 2gVLpmykGiH1wfakR30eknw4iyivGpwyvtEJCZhBMBiZEycyRGxf3DLrF5DBTbYAG5xyQM9Lf slaADlEQBxiTMinOTVRi/YPAxEcMx5TzYlhahbJ0wTY2vRmza0ULHA1N61rr3fixxzNuk8s2U UB0QRh29FXiqUqP3kIwztojHYXh7HO1LebLb3vQ8S77sC5DiZ0ks5SGJG+aV1kUxmNvyd9+cF iP529iXsT7jWh33yXpE7TOEN9Shzk6arReraG9yNPA6RGAd5lU3NItMQJsW2coBwSSH5fMKPT 3UxrXp6xm80W13eJzNwE5WmAJVav2nGoMNUedE+UzK1v6qSXwNVTcpjTq3zUtSjdcZJRhpATN FQV+x/wwZMEymP25pXsdAc3mCQEaVCf6LQjrZ9lO9DQnv0eCTfsP/N3WpIU+iHKojJC6ZUjWV FIbH9lddRLDyBeNI8EFvGW1u+yhoCr89PbvrYL5cABq5IaLj67jL36/MS8lQp8rO9u4m91UFm oTG7q7y98zh2fKvYU3epdUsFVMSOy4+/spmbhSHVQViMem0xuF6dDzqDb0WpRIsEExwCXNo4O aS4sq9MammBHNfYSc5t24cdoEDlDfncvx+2wmaTo13wJwD48hd8YUlkwbr6IFwqqBNButZokC H/+6uNJ6yWVGE/42cp1LzJZTagVMwS9P7Za3HKCu+rSv7dUEIodqnYrmnIqYP7eXagt3TjcWD 8XYoum7q7STVQCGy/WwfaHlOWePfqO+nmTno6b1rpYeVX6ULbBxqhvC9kB9wGBJ1MNEQm+28T B/Qk1+dM0JPoCFpbLJ4auR6BB629GNI6jRqKxHQdHdfY0ZYsGum+QsYNCpT3uZCjgKW9JBEev IFJqyWC34kszgw7gSI3Q== X-Rspamd-Queue-Id: 4D5WwY3FtDz3NPQ X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.45 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_ORG_HEADER(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmx.net:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.95)[-0.946]; RECEIVED_SPAMHAUS_PBL(0.00)[89.12.11.0:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RBL_DBL_DONT_QUERY_IPS(0.00)[212.227.15.18:from]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE]; RCVD_IN_DNSWL_LOW(-0.10)[212.227.15.18:from]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmx.net:s=badeba3b8450]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[walstatt.org]; SPAMHAUS_ZRD(0.00)[212.227.15.18:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_NA(0.00)[no SPF record]; RWL_MAILSPIKE_POSSIBLE(0.00)[212.227.15.18: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.34 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, 30 Dec 2020 13:14:54 -0000 --Sig_/8tXX7vAxhlkt+dhYppWM_C6 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Wed, 30 Dec 2020 12:13:44 +0100 Michael Tuexen wrote: > On 30. Dec 2020, at 08:04, Hartmann, O. wrote: > >=20 > > On recent 12-STABLE, 12.1-RELENG and 12.2-RELENG I face a very nasty pr= oblem which > > occured a while ago after it seemed to have vanished for a while: runni= ng ssh in a > > xterm on FreeBSD boxes as mentioned at the beginning ends up very rapid= ly in a lost > > connection with =20 > How can I reproduce the problem? Just ssh'ing into a server? Client and s= erver running > FreeBSD head? Are there middleboxes (NAT, Firewall) involved or does it a= lso happen if > client and server are directly connected? What does 'rapidly' mean: 1 sec= ond, 1 minute, > 1 hour, 1 day? Take this course: 12-STABLE (FreeBSD 12.2-STABLE #63 r368787+3cc3872829b1(s= table/12): Mon Dec 28 06:07:57 CET 2020 amd64).=20 As a target (server) I just used a LibreELEC box, Leia 18. something, core = 9.2.6. My notebook this time is a Lenovo E540. ssh is running in xterm. After a succe= ssful login on the KODI/LibreElec, wait for a couple of minutes. It is random, the session= of mine died after 2 to 5 minutes of idling, one can extend that timeframe by starting t= op on the KODI/shell. regards oh p.s. That is only one scenario that I faced at home just a couple of minute= s ago. >=20 > Best regards > Michael > >=20 > > # Fssh_packet_write_wait: Connection to XXX.XXX.XXX.XXX port 22: Broken= pipe > >=20 > > The backend is in most cases a CURRENT, 12.1-RELENG or 12.2-RELENG or 1= 2-STABLE > > server. A couple of months ago we moved from 11.3-RELENG to 12.1-RELENG= (server side, > > clients were always 13-CURRENT or 12-STABLE). With FreeBSD 11 as the ba= ckend, those > > broken pipes occured, but not that frequent and rapid as it is the fact= now.=20 > >=20 > > The "problem" can be mitigated somehow: running top or using the consol= e prevents the > > broken pipe fault for a while, but it still occurs. Running "screen" (p= ort > > sysutils/screen) does extend the usability of the console for a signifi= cant timespan, > > but the broken pipe also occurs randomly, but it takes a significant ti= me to occur. > >=20 > > All systems mentioned above are highly customized, so I used the chance= of another, > > more "generic" scenario to test. The backend is a most recent Xigmanas = machine > > (running Hardened FreeBSD 12, latest official issue, its based on FBSD = 12.1). > > Accessing clients are recent GhostBSD or FreeBSD 12.2-RELENG, utilizing= Remmina (port > > sysutils/remmina). It doesn't matter whether I take the ports from our = local > > poudriere driven repository or from one of the official ones. SSH via R= emmina dies > > the same death as it does on all customized boxes. And those failing sc= enarios are > > occur in all kind of networks, home-ISP-lab/work, lab's network, home's= network with > > foreign, Linux based CPE or other vendor's CPE. > >=20 > > My conclusion is: either there is a serious problem with FreeBSD since = 12, or there > > is a config issue I'm not aware of, even with "vanilla" installations f= rom official > > repository running unchanged. > >=20 > > Kind regards, > >=20 > > oh =20 >=20 --Sig_/8tXX7vAxhlkt+dhYppWM_C6 Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQSy8IBxAPDkqVBaTJ44N1ZZPba5RwUCX+x9SAAKCRA4N1ZZPba5 R9HTAQCoylYTmyy5Canw0uTU7uiFMX3cJ9CcnnKGK8toVecKPgD9GYsrKkneZ32J BoBX7imznEGT5Su4CsIeqStztzeKJQk= =aQLR -----END PGP SIGNATURE----- --Sig_/8tXX7vAxhlkt+dhYppWM_C6-- From owner-freebsd-current@freebsd.org Wed Dec 30 15:41: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 D4EE24C63C3 for ; Wed, 30 Dec 2020 15:41:26 +0000 (UTC) (envelope-from warlock@phouka1.phouka.net) Received: from phouka1.phouka.net (phouka1.phouka.net [107.170.196.116]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "phouka.net", Issuer "Go Daddy Secure Certificate Authority - G2" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D5b9d5PXRz3nKF for ; Wed, 30 Dec 2020 15:41:25 +0000 (UTC) (envelope-from warlock@phouka1.phouka.net) Received: from phouka1.phouka.net (localhost [127.0.0.1]) by phouka1.phouka.net (8.16.1/8.16.1) with ESMTPS id 0BUFe26e045987 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 30 Dec 2020 07:40:02 -0800 (PST) (envelope-from warlock@phouka1.phouka.net) Received: (from warlock@localhost) by phouka1.phouka.net (8.16.1/8.16.1/Submit) id 0BUFe2EL045986; Wed, 30 Dec 2020 07:40:02 -0800 (PST) (envelope-from warlock) Date: Wed, 30 Dec 2020 07:40:01 -0800 From: John Kennedy To: "Hartmann, O." Cc: FreeBSD CURRENT Subject: Re: # Fssh_packet_write_wait: Connection to 77.183.250.3 port 22: Broken pipe Message-ID: References: <20201230080403.5474da7c@hermann.fritz.box> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201230080403.5474da7c@hermann.fritz.box> X-Rspamd-Queue-Id: 4D5b9d5PXRz3nKF X-Spamd-Bar: / X-Spamd-Result: default: False [0.20 / 15.00]; ARC_NA(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[107.170.196.116:from]; NEURAL_SPAM_SHORT(1.00)[1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[phouka.net]; AUTH_NA(1.00)[]; SPAMHAUS_ZRD(0.00)[107.170.196.116:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[warlock@phouka.net,warlock@phouka1.phouka.net]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; FROM_NEQ_ENVFROM(0.00)[warlock@phouka.net,warlock@phouka1.phouka.net]; ASN(0.00)[asn:14061, ipnet:107.170.192.0/18, country:US] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 30 Dec 2020 15:41:26 -0000 On Wed, Dec 30, 2020 at 08:04:03AM +0100, Hartmann, O. wrote: > On recent 12-STABLE, 12.1-RELENG and 12.2-RELENG I face a very nasty problem which > occured a while ago after it seemed to have vanished for a while: running ssh in a xterm > on FreeBSD boxes as mentioned at the beginning ends up very rapidly in a lost connection > with > > # Fssh_packet_write_wait: Connection to XXX.XXX.XXX.XXX port 22: Broken pipe > > The backend is in most cases a CURRENT, 12.1-RELENG or 12.2-RELENG or 12-STABLE server. A > couple of months ago we moved from 11.3-RELENG to 12.1-RELENG (server side, clients were > always 13-CURRENT or 12-STABLE). With FreeBSD 11 as the backend, those broken pipes > occured, but not that frequent and rapid as it is the fact now. > > The "problem" can be mitigated somehow: running top or using the console prevents the > broken pipe fault for a while, but it still occurs. Running "screen" (port > sysutils/screen) does extend the usability of the console for a significant timespan, but > the broken pipe also occurs randomly, but it takes a significant time to occur. So, I do a LOT of ssh-in-xterm and I can't say that I've seen anything that looks like it is FreeBSD's fault (vs ISP, work firewall, work VPN, etc). For my cloud host (12.2-p2) I do tend to use the screen program. At work, in pre- Covid times (so up to last March 18th or so, whatever that works out to in versioning/revisions; probably 12.1 or 12.0), I'd have sessions opened a week+. At home I'm all 13 at the moment. Because I'm running a lot of 13 at home (and before that, 12-stable) I tend to reboot the box for update reasons. Is it safe to assume that "very rapidly" is measured in sub-days? > My conclusion is: either there is a serious problem with FreeBSD since 12, or there is a > config issue I'm not aware of, even with "vanilla" installations from official repository > running unchanged. At work, my problems are all about crappy firewalls. Even firewalls that we've spent a LOT of money on (PaloAlto, the Juniper before it). In all fairness to them, we're running a University's worth of class-B through there and they have all the state-tracking/deep-inspection goodness turned on trying to protect everyone from the big bad internet so it's complicated. With putty, I've had to turn on TCP/IP keepalives and sending null packets. The problem there just seems to be that the firewall hardware can only track so many sessions and, when you stress it, it'll drop "idle" sessions (vs active, vs not opening up a new one). Systems hemorrhage connections all the time when something eats the final connection-close packet, but they can time the thing out. The PaloAlto in my case doesn't know that so it just starts reaping, getting valid idle connections some of the time. So all my tricks just involve some amount of traffic to keep that session more alive in the non-host-state-tracker's brain. For SSH at work, I've set this up: host * TCPKeepAlive yes ServerAliveInterval 60 ServerAliveCountMax 3 So, send TCP/IP keepalive packets, send some traffic every 60 seconds, and tear down the session if you miss 3 of those. I'll note at home that I haven't had to do that. For that cloud 12.2 system, I've had a connection "idle" for 21 hours (but running with a screen going, which is getting some amount of bidirectional traffic going because it has a date/time stamp that gets updated once a minute). Is 21 hours "significant" by your measurements? At home, I don't have a network firewall of any sort. Probably the usual unknowns with the ISP and crappyware NAT box they force me to use. My cloud system is running on DigitalOcean, for what that is worth. I'm not sure what they're doing for firewalls (I'm doing host firewalls out there, so maybe nothing in my case). From owner-freebsd-current@freebsd.org Wed Dec 30 15:57: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 058E14C708B; Wed, 30 Dec 2020 15:57:42 +0000 (UTC) (envelope-from uqs@freebsd.org) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2a05:fc87:1:5::15]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "www.spoerlein.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D5bXP49fcz3p61; Wed, 30 Dec 2020 15:57:41 +0000 (UTC) (envelope-from uqs@freebsd.org) Received: from localhost (acme.spoerlein.net [IPv6:2a05:fc87:1:5:0:0:0:15]) by acme.spoerlein.net (8.16.1/8.15.2) with ESMTPS id 0BUFvc6f050295 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 30 Dec 2020 16:57:38 +0100 (CET) (envelope-from uqs@freebsd.org) Date: Wed, 30 Dec 2020 16:57:38 +0100 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: current@freebsd.org, freebsd-current@freebsd.org Subject: Re: git and the loss of revision numbers Message-ID: Mail-Followup-To: current@freebsd.org, freebsd-current@freebsd.org References: <54116640-E6A1-4C53-9D7E-4384F942628E@ellael.org> <8ABAC674-89AA-47BE-996C-4DF6E7713F21@ellael.org> <53dd689b-2401-8e90-f332-50c60c549c2e@FreeBSD.org> <1d1e2003-0cc1-6e67-0ceb-f0fcba03f8f7@twcny.rr.com> <20201229005639.GS31099@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: User-Agent: Mutt/2.0.1 (2020-11-14) X-Rspamd-Queue-Id: 4D5bXP49fcz3p61 X-Spamd-Bar: / X-Spamd-Result: default: False [0.00 / 15.00]; local_wl_from(0.00)[freebsd.org]; ASN(0.00)[asn:39540, ipnet:2a05:fc87::/32, country:CH] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 30 Dec 2020 15:57:42 -0000 On Mon, 2020-12-28 at 17:06:26 -0800, David Wolfskill wrote: >On Mon, Dec 28, 2020 at 04:56:39PM -0800, John-Mark Gurney wrote: >> monochrome wrote this message on Mon, Dec 28, 2020 at 19:38 -0500: >> > what would be the git command for reverting source to a previous version >> > using these numbers? for example, with svn and old numbers: >> > svnlite update -r367627 /usr/src >> > >> > this is needed often when it blows up for someone tracking current >> >> Get the hash from a commit number: >> $git rev-list --reverse HEAD | tail -n +255241 | head -n 1 >> 3cc0c0d66a065554459bd2f9b4f80cc07426464a >> >> so: >> git checkout $(git rev-list --reverse HEAD | tail -n +255240 | head -n 1) >> .... > >Or save a process: > >git rev-list --reverse HEAD | awk 'NR == 255241 {print; exit 0}' >3cc0c0d66a065554459bd2f9b4f80cc07426464a > >(And thus: >git checkout $(git rev-list --reverse HEAD | awk 'NR == 255241 {print; exit 0}') > >Could also pass the number to awk via the "-v var=value" command-line.) Counting commits will not get you to SVN revision 12345, you need to look at the git notes, they are there for that exact reason. (fun fact, r12345 isn't actually on the main branch, so don't try with that one) % git log --oneline -n1 --notes --grep='revision=12346$' main df4f0253cd89 Use NO_MTREE, not !USE_X11 && !USE_IMAKE, to determine package args. NO_MTREE should work as advertised (for both direct installation and pkg_add) now. Notes: svn path=/head/; revision=12346 So df4f0253cd89 is the corresponding git commit to your SVN r12346 hth Uli From owner-freebsd-current@freebsd.org Wed Dec 30 16:04: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 ACF964C7259 for ; Wed, 30 Dec 2020 16:04:20 +0000 (UTC) (envelope-from uqs@freebsd.org) Received: from acme.spoerlein.net (acme.spoerlein.net [IPv6:2a05:fc87:1:5::15]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "www.spoerlein.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D5bh43FM2z3pjx for ; Wed, 30 Dec 2020 16:04:20 +0000 (UTC) (envelope-from uqs@freebsd.org) Received: from localhost (acme.spoerlein.net [IPv6:2a05:fc87:1:5:0:0:0:15]) by acme.spoerlein.net (8.16.1/8.15.2) with ESMTPS id 0BUG4HP0053868 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 30 Dec 2020 17:04:19 +0100 (CET) (envelope-from uqs@freebsd.org) Date: Wed, 30 Dec 2020 17:04:17 +0100 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: monochrome Cc: freebsd-current@freebsd.org Subject: Re: git and the loss of revision numbers Message-ID: Mail-Followup-To: monochrome , freebsd-current@freebsd.org References: <54116640-E6A1-4C53-9D7E-4384F942628E@ellael.org> <8ABAC674-89AA-47BE-996C-4DF6E7713F21@ellael.org> <53dd689b-2401-8e90-f332-50c60c549c2e@FreeBSD.org> <1d1e2003-0cc1-6e67-0ceb-f0fcba03f8f7@twcny.rr.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <1d1e2003-0cc1-6e67-0ceb-f0fcba03f8f7@twcny.rr.com> User-Agent: Mutt/2.0.1 (2020-11-14) X-Rspamd-Queue-Id: 4D5bh43FM2z3pjx X-Spamd-Bar: / X-Spamd-Result: default: False [0.00 / 15.00]; local_wl_from(0.00)[freebsd.org]; ASN(0.00)[asn:39540, ipnet:2a05:fc87::/32, country:CH] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 30 Dec 2020 16:04:20 -0000 On Mon, 2020-12-28 at 19:38:05 -0500, monochrome wrote: >what would be the git command for reverting source to a previous version >using these numbers? for example, with svn and old numbers: >svnlite update -r367627 /usr/src > >this is needed often when it blows up for someone tracking current You need to fetch the git notes, then you can grep them for the SVN rev you're looking for. $ git fetch origin "refs/notes/*:refs/notes/*" && git fetch $ git checkout `git log --format=%h --notes --grep='revision=367627$' main` It's git commit 9aa6d792b549 for reference. >On 12/28/20 11:27 AM, Ed Maste wrote: >> On Mon, 28 Dec 2020 at 07:08, Renato Botelho wrote: >>> >>> FreeBSD bast.garga.net.br 13.0-CURRENT FreeBSD 13.0-CURRENT #19 >>> 3cc0c0d66a0-c255241(main)-dirty: >>> ^ >>> This is an incremental counter of commits >> >> Also, uqs@ recently fixed an issue in newvers.sh (including the final, >> non-updating svn revision) and reordered the information. An example >> of the new format: >> >> main-c255126-gb81783dc98e6-dirty >> \ \ \ \ >> \ \ \ local modifications >> \ \ hash >> \ commit count >> branch Note, the `g` in there is by design, it's the format that git-describe will barf out. hth Uli From owner-freebsd-current@freebsd.org Wed Dec 30 16:08: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 764774C7A09 for ; Wed, 30 Dec 2020 16:08:59 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mx.catwhisker.org (mx.catwhisker.org [107.204.234.170]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4D5bnQ3Xxxz3qSm for ; Wed, 30 Dec 2020 16:08:58 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.16.1/8.15.2) with ESMTP id 0BUG8otK043357; Wed, 30 Dec 2020 16:08:50 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.16.1/8.16.1/Submit) id 0BUG8orU043356; Wed, 30 Dec 2020 08:08:50 -0800 (PST) (envelope-from david) Date: Wed, 30 Dec 2020 08:08:50 -0800 From: David Wolfskill To: "Hartmann, O." Cc: FreeBSD CURRENT Subject: Re: # Fssh_packet_write_wait: Connection to 77.183.250.3 port 22: Broken pipe Message-ID: Mail-Followup-To: David Wolfskill , "Hartmann, O." , FreeBSD CURRENT References: <20201230080403.5474da7c@hermann.fritz.box> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="i7MDvwBGNnSXWh8r" Content-Disposition: inline In-Reply-To: <20201230080403.5474da7c@hermann.fritz.box> X-Rspamd-Queue-Id: 4D5bnQ3Xxxz3qSm X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.40 / 15.00]; RCVD_TLS_LAST(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[107.204.234.170:from]; FREEFALL_USER(0.00)[david]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:107.204.234.170]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[catwhisker.org]; ARC_NA(0.00)[]; NEURAL_SPAM_SHORT(1.00)[1.000]; SPAMHAUS_ZRD(0.00)[107.204.234.170:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:7018, ipnet:107.192.0.0/12, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 30 Dec 2020 16:08:59 -0000 --i7MDvwBGNnSXWh8r Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Dec 30, 2020 at 08:04:03AM +0100, Hartmann, O. wrote: > ... >=20 > # Fssh_packet_write_wait: Connection to XXX.XXX.XXX.XXX port 22: Broken p= ipe >=20 > The backend is in most cases a CURRENT, 12.1-RELENG or 12.2-RELENG or 12-= STABLE server. A > couple of months ago we moved from 11.3-RELENG to 12.1-RELENG (server sid= e, clients were > always 13-CURRENT or 12-STABLE). With FreeBSD 11 as the backend, those br= oken pipes > occured, but not that frequent and rapid as it is the fact now.=20 >=20 > The "problem" can be mitigated somehow: running top or using the console = prevents the > broken pipe fault for a while, but it still occurs. Running "screen" (port > sysutils/screen) does extend the usability of the console for a significa= nt timespan, but > the broken pipe also occurs randomly, but it takes a significant time to = occur. I have seen messages like that -- from a remote host that has rebooted or to which the network connection has (otherwise) been severed. A couple of things that I do may have (significantly) reduced the probability that I would encounter what you report under other conditions. Context: I work from my laptop, and ssh to ... well, just about everything: machines in my house; machines at work; machines at work accessible only from within the VPN hrough a bastion host; machines in the FreeBSD.org cluster.... Usually concurrently. The laptop normally runs FreeBSD stable/12 (freshly built each morning), but it runs head while I build head on it and for the smoke-test after the build is complete. * A long time ago, I placed "ServerAliveInterval 150" in ~/.ssh/config. (I suspect that this was well before Nov 2014, which was the beginning of my tenure with my current employer. And yes, I had been using the above-described "ssh to everyhing" well before then -- I think I got in he habit around 1999, back at Whistle.) * Whenever I am about to do something "sensitive," I run tmux (port/package sysutils/tmux -- same "ecological niche" as screen, but I switched from screen to tmux several years ago, and haven't looked back.) This has become enough of a habit that I tend to run tmux from "muscle memory." Or I have set up csh aliasses or scripts to "do stuff" that automagically invoke tmux, so I don't even notice. * [Yeah, I wrote "a couple" up there; this is a bonus. :-) ] I don't keep machines up longer than about 175 hours (a little over a week) at a stretch: I update my laptop and my "build machine" daily, and update the other machines under my control weekly. > ....=20 Peace, david --=20 David H. Wolfskill david@catwhisker.org While Trump successfully conned a lot of people for a while, in the end he's just a failure throwing a temper tantrum because he lost. See https://www.catwhisker.org/~david/publickey.gpg for my public key. --i7MDvwBGNnSXWh8r Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAEBCgB9FiEE4owz2QxMJyaxAefyQLJg+bY2PckFAl/sphJfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEUy OEMzM0Q5MEM0QzI3MjZCMTAxRTdGMjQwQjI2MEY5QjYzNjNEQzkACgkQQLJg+bY2 Pcke2Af/R2x7HE2gf2hslaU/lYnjT7RmUGHQOltndv2szEv1k6GKxvxPbt7xvXZL 6dDNDKa6nm0qJaUoGbs+u9n+sCxlzN4XMHi71PLi6jFBGbiyYxcPGzofqeVi2zpu 1lQ+66xyLThO6lmze169sesVS9jjFVMtu0InRQsyXu+JQ5V8hnpc46n5aUA3igyA rgjAKi9IKVWwtbIggoEXUS6V+HrMNaGzNG8kp1oNf0DGSNKYi7gu+OnY3rn/NRA9 RXY9c6gYOF2jdmK4TZeTZGP7m4LSxoU5baVH8o4goAEphb0OALVg86zHRdvh/ZTG 0oV+i35Y39bsSECkC84jPBQ2ZAAd8g== =fnwN -----END PGP SIGNATURE----- --i7MDvwBGNnSXWh8r-- From owner-freebsd-current@freebsd.org Wed Dec 30 16:48: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 ACC694C89B3 for ; Wed, 30 Dec 2020 16:48:37 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-to1can01on062c.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe5d::62c]) (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 4D5cg93hjBz3spx; Wed, 30 Dec 2020 16:48:37 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JybeFmH6gTBryuPxG6HzQ7znISkZ4ir1ved9sHjlI5vcWRbNTxpn14pS/ZM8wHAOfTUtIA6Ng0ljvRQsd19fE9o7P+idEdmg6oEz/jv0ECNtWtOLDMSmTV1b9drD8210hZ2M4MDxYumc1qnWidiB0clr2Q3ljG353DfHys6zSL0iRklpqaIUPqGR4khLHouDatd4lUbx2YHFX0YvDuurzUb06bgu+CTqrvYnLbPMcegUws0Zpsmd/MCH8mFu4UfKViEVx3FgVBerEP/44kMITv/MO3DKwf/07AqWP+tRfLMnpGLl0g2ASuclWP6He+NwOSjhqWkZ1/8/ua6ag72xjg== 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=idNS+xLra0eHmU4dhwyXbB/cU0R7177cvOyAqLq2epA=; b=AZBkL8e+29+ZzU856ybr1dzI3bczWgzgrvYrPaeNeEaNgh9feD8eGb4nNJSIJ8XVG3Q5N5jUc8+BtIsa2AkEYebXfx07nGHfz+bGN0qQt7R46wG8pz420qMBqF0FgyVtSKBbz0sFNMmcGji5QuTV0EwCxm602BpUTpyfExaG7qdKMXusG4B5M3rXvmrSPLdZxQo0KF/RU45SvPB8HIOg16mVJRx32iMC2jbUb8zRlaLDZ7t5POT1Vweu1ERXo6Z4o4VfLul8clbl3z3qizZtyo0bvf5E6ApmNyqCBn9ESX+U3U6NZmbh6hWZLG9fvTHKMam119Os8lCDtPJrTc0Wig== 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 YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:19::29) by YQXPR01MB3909.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:4e::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3721.20; Wed, 30 Dec 2020 16:48:35 +0000 Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::3d86:c7f9:bc4c:40c0]) by YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::3d86:c7f9:bc4c:40c0%6]) with mapi id 15.20.3721.020; Wed, 30 Dec 2020 16:48:27 +0000 From: Rick Macklem To: Konstantin Belousov CC: "freebsd-current@freebsd.org" , Alan Somers , Kirk McKusick , Mark Johnston Subject: Re: r367672 broke the NFS server Thread-Topic: r367672 broke the NFS server Thread-Index: AQHW3k3ynlL3lGhXRkC37zjbBa1PUKoPmNaAgAA7NVY= Date: Wed, 30 Dec 2020 16:48:27 +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: 9218ba02-00a8-4d2d-8751-08d8ace2bb2a x-ms-traffictypediagnostic: YQXPR01MB3909: 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: J/hWd2jzcqYmxGjYRbxZhbJvIsOyNQrg5LZ9dJAAiARB0bpnGRYf0ALjLg5udsQIdrl1Df8fuRfpZX/ckIBedRb90FoEw61sOOmIQ1De4hP1scXoYzuM+SphjaN0CCkhMIXQdaVjrsDZ7+b2ctL0d1ThdvApOkTz5sdvSp+VRjOPSJ2qNnu649UjvEDCHmKBIVGs6Ljuii9uMSzqboIAL5mWyYCKC07axLOA/qvgrFCHr6EA6upc8LBAa4rRNdfKGdmYcYrgds04FEE6fdgvrm2/bpy9beeIv4MsuYkAMoVlVRIObDy0HqIRzGMPWzA86wlwv626+YgeimlRzeMFAhDlzpriqkxpqEdRhDvYgIl1eT8PIp4EOjZAgKTY3dMK8LxmOrNHX55++r3KuIFQniAIdnAC+QKJmcABcGV+S+rZnFWiquV03dvmoVzgccSJJFYxQoLVI3ghjau6Qqp/Qw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(376002)(136003)(396003)(39850400004)(346002)(366004)(66476007)(66946007)(8676002)(86362001)(66556008)(55016002)(91956017)(966005)(2906002)(8936002)(76116006)(54906003)(786003)(9686003)(316002)(66446008)(64756008)(478600001)(6506007)(33656002)(83380400001)(6916009)(4326008)(71200400001)(52536014)(186003)(26005)(5660300002)(7696005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?UTNjAnHf48rKxe/sJzN5/9UIWpuFNUC91pW71RYJdFJ3gO865KiBKOrINq?= =?iso-8859-1?Q?HF9laI1RXL+KdB17rfeVMe4g2+UYJJKHcpi/hTR+KkK7J5iwVe6S9pR+LP?= =?iso-8859-1?Q?S/xaXQ7BKW26rQG7Xs81iwLxoZ2Sfe/E3O1zHpwFU0tUVIv6onxhB3kCw3?= =?iso-8859-1?Q?QgZzbTGuvN8qSNIC00mTfGtoSibTA5tciMN/lucpMTdNXXyrfu7ogJTH5E?= =?iso-8859-1?Q?RXEkF0wjIV2clfkJL6+vGvLwjsgNv2VdhwyeoS11ORuiFmcUOkSqkMsSyH?= =?iso-8859-1?Q?nseuinq0ihHYHDLRJ+hwdAB5jdcUYnqkGq/s+yN2ZFFGDbGTYWhrUXOkCD?= =?iso-8859-1?Q?HF27Hgcr0hOYQnl6hE0TveR6qszocXS7e9+iotEDMLXO3h/v+P92OJoFt6?= =?iso-8859-1?Q?tIHD4hzoTKvXM4TVmgV2bXBwrr5CD/ixcRusIBI4G5eXIhAaQubsVEsQ62?= =?iso-8859-1?Q?Xu6AmrpmYAzzuvoRNWhhgJkc9eVHf4gudtNIywGetao9PB/3ZF75a21odY?= =?iso-8859-1?Q?Jgcye3cyFd4VwfhvbIegLLO3PeF8r7e3HMYQB6ZS9GAqSRbB/WVk2pxnhK?= =?iso-8859-1?Q?PXdVTzVRo1uplo29TR5pX7sy4uNcMVJQRKnrnhyHBi6maucm89nkII27GH?= =?iso-8859-1?Q?sNLxMbQ7ENC88J5emEqp44BrFPy2ySjsVTPpYxTZLAdYxZITItNDykwBsf?= =?iso-8859-1?Q?/J1WvmMjpOwTxsJlOLbV2Kh7XaAdchfBv1WuPYvrSe2kQfNZnzakqHkPNx?= =?iso-8859-1?Q?1EoS8mo4U/9u7qOgILn5QyM3qQGalp1BsXLIHZnM0YROI6krtcKxG/V3yq?= =?iso-8859-1?Q?XYtQQSuOjZlP8YC65vr4IIMqJKx+qR0FrlCsBZ3tyKlikyNlVktZxwKS4A?= =?iso-8859-1?Q?Kf2wcb3osLcW/QmGdwoOUngDT+vTuyNFih3UynQDlE8m/p9/Qfi+xViFc5?= =?iso-8859-1?Q?TyPawiLLjbeG3ilujIVQ9a+BsGpji0XBiRAmxx3mHsOYCjHJdsDFAxbm3W?= =?iso-8859-1?Q?J4HtbSM69dhjwirD4=3D?= 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: YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 9218ba02-00a8-4d2d-8751-08d8ace2bb2a X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Dec 2020 16:48:27.5108 (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: cism0sr3aO8morZKRUB2HhWDraAr3VkjS2TBBavAWw71NmEcTBZTpQltl+4D3rRFYwAywJZWNIdiBSrwcYGGSw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQXPR01MB3909 X-Rspamd-Queue-Id: 4D5cg93hjBz3spx X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 30 Dec 2020 16:48:37 -0000 Kostik wrote:=0A= >On Wed, Dec 30, 2020 at 02:02:48AM +0000, Rick Macklem wrote:=0A= >> Hi,=0A= >>=0A= >> Post r367671...=0A= >> When multiple files are being created by an NFS client in the same=0A= >> directory, the VOP_CREATE()/ufs_create() can fail with ERELOOKUP.=0A= >> This results in a EIO return to the NFS client.=0A= >> --> This causes "nfsv4 client/server protocol prob err=3D10026"=0A= >> on the client for NFSv4.0 mounts.=0A= >> --> This explains why this error has been reported by=0A= >> several people lately, although it should "never happen".=0A= >>=0A= >> Unfortunately, for the NFS server, the Lookup call is done separately=0A= >> and it will not be easy to redo it, given the current NFS code structure= .=0A= >>=0A= >> Is there another way to deal with the problem r367672 was fixing that=0A= >> avoids ufs_create() returning ERELOOKUP?=0A= >=0A= >Idea of the change is to restart the syscall at top level. So for NFS=0A= >server the right approach is to not send a response and also to not=0A= >free the request mbuf chain, but to restart processing.=0A= Yes. I took a look and I think restarting the operation by rolling the=0A= working position in the mbuf lists back and redoing the operation=0A= is feasible and easier than fixing the individual operations.=0A= =0A= For NFSv4, you cannot redo the entire compound, since non-idempotent=0A= operations like exclusive open may have already been completed.=0A= However, rolling back to the beginning of the operation should be=0A= doable.=0A= --> It will serve as a good test, in that it may expose bugs in the=0A= RPC/operation code where failure (ERELOOKUP) doesn't clean=0A= things up correctly.=0A= --> In NFSv4, there is the open/lock state that cannot be updated=0A= for this error case. (The seqid stuff in NFSv4.0 Open can be fu= n.=0A= Its used to serialize the operations and the number must be=0A= incremented for some errors, but not for others. The 10026=0A= error occurs when you don't get this right.)=0A= =0A= I'll start working on this to-day, but I have no idea how long it might=0A= take?=0A= =0A= >I am sorry I forgot about NFS server when designing this fix, the only=0A= >mild excuse I can provide is that the change was quite complicated as is.= =0A= >I will start looking at the fix.=0A= No problem. Sometimes I'd like to forget about NFS too;-).=0A= =0A= For the rollback/redo the RPC/operation case, it's probably easier for me= =0A= to do it. As above, I'll start on it, but...=0A= =0A= My main concern is how long it will take, given the FreeBSD13 release=0A= starts soon.=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 Wed Dec 30 17:27:17 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 5D35B4C90F9 for ; Wed, 30 Dec 2020 17:27:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4D5dWm6b4wz3vpt; Wed, 30 Dec 2020 17:27:16 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 0BUHR8d9002418 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 30 Dec 2020 19:27:11 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 0BUHR8d9002418 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 0BUHR8SF002416; Wed, 30 Dec 2020 19:27:08 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Wed, 30 Dec 2020 19:27:08 +0200 From: Konstantin Belousov To: Rick Macklem Cc: "freebsd-current@freebsd.org" , Alan Somers , Kirk McKusick , Mark Johnston Subject: Re: r367672 broke the NFS server Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on tom.home X-Rspamd-Queue-Id: 4D5dWm6b4wz3vpt X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 30 Dec 2020 17:27:17 -0000 On Wed, Dec 30, 2020 at 04:48:27PM +0000, Rick Macklem wrote: > Kostik wrote: > >On Wed, Dec 30, 2020 at 02:02:48AM +0000, Rick Macklem wrote: > >> Hi, > >> > >> Post r367671... > >> When multiple files are being created by an NFS client in the same > >> directory, the VOP_CREATE()/ufs_create() can fail with ERELOOKUP. > >> This results in a EIO return to the NFS client. > >> --> This causes "nfsv4 client/server protocol prob err=10026" > >> on the client for NFSv4.0 mounts. > >> --> This explains why this error has been reported by > >> several people lately, although it should "never happen". > >> > >> Unfortunately, for the NFS server, the Lookup call is done separately > >> and it will not be easy to redo it, given the current NFS code structure. > >> > >> Is there another way to deal with the problem r367672 was fixing that > >> avoids ufs_create() returning ERELOOKUP? > > > >Idea of the change is to restart the syscall at top level. So for NFS > >server the right approach is to not send a response and also to not > >free the request mbuf chain, but to restart processing. > Yes. I took a look and I think restarting the operation by rolling the > working position in the mbuf lists back and redoing the operation > is feasible and easier than fixing the individual operations. > > For NFSv4, you cannot redo the entire compound, since non-idempotent > operations like exclusive open may have already been completed. > However, rolling back to the beginning of the operation should be > doable. > --> It will serve as a good test, in that it may expose bugs in the > RPC/operation code where failure (ERELOOKUP) doesn't clean > things up correctly. > --> In NFSv4, there is the open/lock state that cannot be updated > for this error case. (The seqid stuff in NFSv4.0 Open can be fun. > Its used to serialize the operations and the number must be > incremented for some errors, but not for others. The 10026 > error occurs when you don't get this right.) Note that ERELOOKUP error can only show up from the VOPs that modify the volume. Otherwise we simply do not call into SU. In particular, I believe that opens in the sense of NFS are safe. Regardless of it, there should be either a catch-all check for ERELOOKUP, or assert that ERELOOKUP did not leaked, as it is done for syscalls > > I'll start working on this to-day, but I have no idea how long it might > take? > > >I am sorry I forgot about NFS server when designing this fix, the only > >mild excuse I can provide is that the change was quite complicated as is. > >I will start looking at the fix. > No problem. Sometimes I'd like to forget about NFS too;-). > > For the rollback/redo the RPC/operation case, it's probably easier for me > to do it. As above, I'll start on it, but... > > My main concern is how long it will take, given the FreeBSD13 release > starts soon. For sure I will help you if needed, and I believe that we could ask for testing from Peter. From owner-freebsd-current@freebsd.org Wed Dec 30 18:04: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 742284CA900; Wed, 30 Dec 2020 18:04:51 +0000 (UTC) (envelope-from ctuffli@gmail.com) Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com [IPv6:2607:f8b0:4864:20::b32]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D5fM64MMCz4Spm; Wed, 30 Dec 2020 18:04:50 +0000 (UTC) (envelope-from ctuffli@gmail.com) Received: by mail-yb1-xb32.google.com with SMTP id x2so15464711ybt.11; Wed, 30 Dec 2020 10:04:50 -0800 (PST) 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=opHY58yAjiiMUVrWfnz7SpdcNjJO7ECfzt5SHKr6b8w=; b=GRllFZHOdUg9dTDn5zAstThKHTLVzV/GtBKyiK4xTLicPIX4Ip49pGEjR8mI52JtWg R7qImP7GsweCT05SR/HgxhKqJ1QMJg5lUrb3PV1cefWHN7azK/iBXriPEReYkiDi+Acc SbvuavUyEG/tIxFDItsZcQ3EpvfZ2uhFWK8uTpNnAJqks5/OSkKW/XXGNyS9RsIWRYgE 24aYF2+/FrbBKByRxifl79tcE9IdI+HE1O5Pps6tw+1IvBBp6VyxtDLjQw9e00jbkRX5 eAfUU8z72mcProqibMIq9dIM9mZm5rnZ6aLdovhUnHqgfFX7X5C8wa2ATLtLSVbzSAYL JMLA== X-Gm-Message-State: AOAM532a8WFjTDxwVOirq+/ciFMOso0D1DUVdt/6tgIVS592SB+E5CuY ohbirSncBXYcmfXfT8p6xhAnk+7KpdIA0ZzYzuU= X-Google-Smtp-Source: ABdhPJyRhCA5s0AvVkK4E1wyTpU9Wob3PwdnKYYeZIznTIWga7iHRbBa9cdNE91zmYrbGjr+aF5Cqhfa2WGoReApftw= X-Received: by 2002:a5b:b49:: with SMTP id b9mr73025295ybr.310.1609351489683; Wed, 30 Dec 2020 10:04:49 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Chuck Tuffli Date: Wed, 30 Dec 2020 10:04:38 -0800 Message-ID: Subject: Re: Intel TigerLake NVMe vmd: Adding Support & Debugging a Patch To: Neel Chauhan Cc: freebsd-hackers@freebsd.org, FreeBSD-Current Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4D5fM64MMCz4Spm X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.00 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_SHORT(1.00)[0.998]; RBL_DBL_DONT_QUERY_IPS(0.00)[2607:f8b0:4864:20::b32:from]; TO_DN_SOME(0.00)[]; SPAMHAUS_ZRD(0.00)[2607:f8b0:4864:20::b32:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::b32:from]; NEURAL_HAM_LONG(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-hackers,freebsd-current]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 30 Dec 2020 18:04:51 -0000 On Tue, Dec 29, 2020 at 6:30 PM Neel Chauhan wrote: > > Hi freebsd-hackers@, CC'd freebsd-current@, > > I hope you all had a wonderful holiday season. > > I recently got a HP Spectre x360 13t-aw200 which is an Intel > TigerLake-based laptop. It has the Intel "Evo" branding and an "Optane" > SSD which I disabled (so I can get a "second" SSD). > > On the Spectre, the NVMe is not detected: https://imgur.com/a/ighTwHQ > > I don't know if it is HP or Intel, but the VMD IDs device id is > 8086:9a0b. I'm guessing Intel since Dell laptops (XPS, Vostro) also have > this device ID [1]. > > Sadly, NVMe RAID is forced on this laptop. > > I wrote a rough patch to add the device IDs, and the patch is below: FWIW, that is the same change I would have made. Peeking at the Linux vmd driver, it doesn't appear to do anything special for 8086:9a0b as compared to the 8086:2a0c device the FreeBSD driver already supports. That said, the Linux driver reads a capability register to determine the bus number start (vmd_bus_number_start()) which I don't see in the FreeBSD driver. This is curious because, looking at the "lspci all" output from the XPS link you provided, the NVMe device shows up in PCI domain 0x1000 (i.e. not 0x0000). Which (and I have no direct experience with this device or code) only happens if the bus number start function returns 0x0. What is the output from # pciconf -rb pci0:0:14:0 0x40:0x48 --chuck From owner-freebsd-current@freebsd.org Wed Dec 30 18:23:15 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 53EB44CB069 for ; Wed, 30 Dec 2020 18:23:15 +0000 (UTC) (envelope-from pho@holm.cc) Received: from relay05.pair.com (relay05.pair.com [216.92.24.67]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4D5fmM1v6Fz4VCh; Wed, 30 Dec 2020 18:23:14 +0000 (UTC) (envelope-from pho@holm.cc) Received: from x8.osted.lan (5.186.117.10.cgn.fibianet.dk [5.186.117.10]) by relay05.pair.com (Postfix) with ESMTP id 154FA1A2D5C; Wed, 30 Dec 2020 13:23:13 -0500 (EST) Received: from x8.osted.lan (localhost [127.0.0.1]) by x8.osted.lan (8.15.2/8.15.2) with ESMTPS id 0BUINDU1022375 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Wed, 30 Dec 2020 19:23:13 +0100 (CET) (envelope-from pho@x8.osted.lan) Received: (from pho@localhost) by x8.osted.lan (8.15.2/8.15.2/Submit) id 0BUINDld022374; Wed, 30 Dec 2020 19:23:13 +0100 (CET) (envelope-from pho) Date: Wed, 30 Dec 2020 19:23:13 +0100 From: Peter Holm To: Konstantin Belousov Cc: Rick Macklem , "freebsd-current@freebsd.org" , Alan Somers , Kirk McKusick , Mark Johnston Subject: Re: r367672 broke the NFS server Message-ID: <20201230182313.GA22299@x8.osted.lan> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4D5fmM1v6Fz4VCh X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 30 Dec 2020 18:23:15 -0000 On Wed, Dec 30, 2020 at 07:27:08PM +0200, Konstantin Belousov wrote: > On Wed, Dec 30, 2020 at 04:48:27PM +0000, Rick Macklem wrote: > > Kostik wrote: > > >On Wed, Dec 30, 2020 at 02:02:48AM +0000, Rick Macklem wrote: > > >> Hi, > > >> > > >> Post r367671... > > >> When multiple files are being created by an NFS client in the same > > >> directory, the VOP_CREATE()/ufs_create() can fail with ERELOOKUP. > > >> This results in a EIO return to the NFS client. > > >> --> This causes "nfsv4 client/server protocol prob err=10026" > > >> on the client for NFSv4.0 mounts. > > >> --> This explains why this error has been reported by > > >> several people lately, although it should "never happen". > > >> > > >> Unfortunately, for the NFS server, the Lookup call is done separately > > >> and it will not be easy to redo it, given the current NFS code structure. > > >> > > >> Is there another way to deal with the problem r367672 was fixing that > > >> avoids ufs_create() returning ERELOOKUP? > > > > > >Idea of the change is to restart the syscall at top level. So for NFS > > >server the right approach is to not send a response and also to not > > >free the request mbuf chain, but to restart processing. > > Yes. I took a look and I think restarting the operation by rolling the > > working position in the mbuf lists back and redoing the operation > > is feasible and easier than fixing the individual operations. > > > > For NFSv4, you cannot redo the entire compound, since non-idempotent > > operations like exclusive open may have already been completed. > > However, rolling back to the beginning of the operation should be > > doable. > > --> It will serve as a good test, in that it may expose bugs in the > > RPC/operation code where failure (ERELOOKUP) doesn't clean > > things up correctly. > > --> In NFSv4, there is the open/lock state that cannot be updated > > for this error case. (The seqid stuff in NFSv4.0 Open can be fun. > > Its used to serialize the operations and the number must be > > incremented for some errors, but not for others. The 10026 > > error occurs when you don't get this right.) > Note that ERELOOKUP error can only show up from the VOPs that modify the volume. > Otherwise we simply do not call into SU. In particular, I believe that opens > in the sense of NFS are safe. > > Regardless of it, there should be either a catch-all check for ERELOOKUP, > or assert that ERELOOKUP did not leaked, as it is done for syscalls > > > > > I'll start working on this to-day, but I have no idea how long it might > > take? > > > > >I am sorry I forgot about NFS server when designing this fix, the only > > >mild excuse I can provide is that the change was quite complicated as is. > > >I will start looking at the fix. > > No problem. Sometimes I'd like to forget about NFS too;-). > > > > For the rollback/redo the RPC/operation case, it's probably easier for me > > to do it. As above, I'll start on it, but... > > > > My main concern is how long it will take, given the FreeBSD13 release > > starts soon. > For sure I will help you if needed, and I believe that we could ask for > testing from Peter. Absolutely. Not sure how I missed running NFS test the first time around. - Peter > _______________________________________________ > 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 Dec 31 00:38: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 0D7654D4A04; Thu, 31 Dec 2020 00:38:25 +0000 (UTC) (envelope-from neel@neelc.org) Received: from rainpuddle.neelc.org (rainpuddle.neelc.org [66.42.69.219]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4D5q5D0Db9z3CHm; Thu, 31 Dec 2020 00:38:23 +0000 (UTC) (envelope-from neel@neelc.org) Received: from mail.neelc.org (rainpuddle.neelc.org [IPv6:2001:19f0:8001:fed:5400:2ff:fe73:c622]) by rainpuddle.neelc.org (Postfix) with ESMTPSA id 9C7C5EB2A5; Wed, 30 Dec 2020 16:38:16 -0800 (PST) MIME-Version: 1.0 Date: Wed, 30 Dec 2020 16:38:16 -0800 From: Neel Chauhan To: Chuck Tuffli Cc: freebsd-hackers@freebsd.org, FreeBSD-Current Subject: Re: Intel TigerLake NVMe vmd: Adding Support & Debugging a Patch In-Reply-To: References: User-Agent: Roundcube Webmail/1.4.9 Message-ID: X-Sender: neel@neelc.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4D5q5D0Db9z3CHm X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.80 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEFALL_USER(0.00)[neel]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+a]; ARC_NA(0.00)[]; SPAMHAUS_ZRD(0.00)[66.42.69.219:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[66.42.69.219:from]; NEURAL_HAM_LONG(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[neelc.org,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:20473, ipnet:66.42.64.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-current,freebsd-hackers] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 31 Dec 2020 00:38:25 -0000 Hi Chuck, On 2020-12-30 10:04, Chuck Tuffli wrote: > What is the output from > # pciconf -rb pci0:0:14:0 0x40:0x48 The output is: 01 00 00 00 01 2e 68 02 00 > --chuck I was also able to stop kernel panics by adding: rman_fini(&sc->vmd_bus.rman); In the fail: statement in vmd_attach(). But I still cannot detect the SSD. -Neel From owner-freebsd-current@freebsd.org Thu Dec 31 01:21:18 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 3B4524D667E; Thu, 31 Dec 2020 01:21:18 +0000 (UTC) (envelope-from neel@neelc.org) Received: from rainpuddle.neelc.org (rainpuddle.neelc.org [66.42.69.219]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4D5r2j0swBz3GjR; Thu, 31 Dec 2020 01:21:16 +0000 (UTC) (envelope-from neel@neelc.org) Received: from mail.neelc.org (rainpuddle.neelc.org [IPv6:2001:19f0:8001:fed:5400:2ff:fe73:c622]) by rainpuddle.neelc.org (Postfix) with ESMTPSA id 9892FEB2A5; Wed, 30 Dec 2020 17:21:14 -0800 (PST) MIME-Version: 1.0 Date: Wed, 30 Dec 2020 17:21:14 -0800 From: Neel Chauhan To: Chuck Tuffli Cc: freebsd-hackers@freebsd.org, FreeBSD-Current Subject: Re: Intel TigerLake NVMe vmd: Adding Support & Debugging a Patch In-Reply-To: References: User-Agent: Roundcube Webmail/1.4.9 Message-ID: <3c55d6d50b1bcf1d45d4599502060f34@neelc.org> X-Sender: neel@neelc.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4D5r2j0swBz3GjR X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.72 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEFALL_USER(0.00)[neel]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+a]; ARC_NA(0.00)[]; SPAMHAUS_ZRD(0.00)[66.42.69.219:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[66.42.69.219:from]; NEURAL_HAM_LONG(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[neelc.org,none]; NEURAL_HAM_SHORT(-0.92)[-0.920]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:20473, ipnet:66.42.64.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-current,freebsd-hackers] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 31 Dec 2020 01:21:18 -0000 To extend, I am getting an issue with `pci_read_device()` where it returns a `vid` (PCI Vendor ID) of 0xffff. This ends up returning "Cannot allocate dinfo!" from vmd. Log (via grep): https://imgur.com/a/tAmmY7i -Neel On 2020-12-30 16:38, Neel Chauhan wrote: > Hi Chuck, > > On 2020-12-30 10:04, Chuck Tuffli wrote: >> What is the output from >> # pciconf -rb pci0:0:14:0 0x40:0x48 > > The output is: > > 01 00 00 00 01 2e 68 02 00 > >> --chuck > > I was also able to stop kernel panics by adding: > > rman_fini(&sc->vmd_bus.rman); > > In the fail: statement in vmd_attach(). > > But I still cannot detect the SSD. > > -Neel > _______________________________________________ > 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 Dec 31 02:14:40 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 077434D89D2; Thu, 31 Dec 2020 02:14:40 +0000 (UTC) (envelope-from neel@neelc.org) Received: from rainpuddle.neelc.org (rainpuddle.neelc.org [66.42.69.219]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4D5sDH0wxFz3LGY; Thu, 31 Dec 2020 02:14:38 +0000 (UTC) (envelope-from neel@neelc.org) Received: from mail.neelc.org (rainpuddle.neelc.org [IPv6:2001:19f0:8001:fed:5400:2ff:fe73:c622]) by rainpuddle.neelc.org (Postfix) with ESMTPSA id BA200EB2A5; Wed, 30 Dec 2020 18:14:36 -0800 (PST) MIME-Version: 1.0 Date: Wed, 30 Dec 2020 18:14:36 -0800 From: Neel Chauhan To: Chuck Tuffli Cc: freebsd-hackers@freebsd.org, FreeBSD-Current Subject: Re: Intel TigerLake NVMe vmd: Adding Support & Debugging a Patch In-Reply-To: <3c55d6d50b1bcf1d45d4599502060f34@neelc.org> References: <3c55d6d50b1bcf1d45d4599502060f34@neelc.org> User-Agent: Roundcube Webmail/1.4.9 Message-ID: X-Sender: neel@neelc.org Content-Type: multipart/mixed; boundary="=_2d58dca25f95ab28b533ae54b1567b6b" X-Rspamd-Queue-Id: 4D5sDH0wxFz3LGY X-Spamd-Bar: - X-Spamd-Result: default: False [-1.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+a:c]; HAS_ATTACHMENT(0.00)[]; MIME_BASE64_TEXT_BOGUS(1.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MIME_BASE64_TEXT(0.10)[]; CTYPE_MIXED_BOGUS(1.00)[]; DMARC_POLICY_ALLOW(-0.50)[neelc.org,none]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[66.42.69.219:from]; ASN(0.00)[asn:20473, ipnet:66.42.64.0/20, country:US]; R_DKIM_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[neel]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; SPAMHAUS_ZRD(0.00)[66.42.69.219:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current,freebsd-hackers] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 31 Dec 2020 02:14:40 -0000 --=_2d58dca25f95ab28b533ae54b1567b6b Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed I have attached two files: * pcidump.txt: A dump of `pciconf -lv` * acpidump.txt: A dump of `acpidump` Hope this can help. -Neel On 2020-12-30 17:21, Neel Chauhan wrote: > To extend, I am getting an issue with `pci_read_device()` where it > returns a `vid` (PCI Vendor ID) of 0xffff. > > This ends up returning "Cannot allocate dinfo!" from vmd. > > Log (via grep): https://imgur.com/a/tAmmY7i > > -Neel > > On 2020-12-30 16:38, Neel Chauhan wrote: >> Hi Chuck, >> >> On 2020-12-30 10:04, Chuck Tuffli wrote: >>> What is the output from >>> # pciconf -rb pci0:0:14:0 0x40:0x48 >> >> The output is: >> >> 01 00 00 00 01 2e 68 02 00 >> >>> --chuck >> >> I was also able to stop kernel panics by adding: >> >> rman_fini(&sc->vmd_bus.rman); >> >> In the fail: statement in vmd_attach(). >> >> But I still cannot detect the SSD. >> >> -Neel >> _______________________________________________ >> 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" > _______________________________________________ > 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" --=_2d58dca25f95ab28b533ae54b1567b6b Content-Transfer-Encoding: base64 Content-Type: text/plain; name=pcidump.txt Content-Disposition: attachment; filename=pcidump.txt; size=5467 aG9zdGIwQHBjaTA6MDowOjA6CWNsYXNzPTB4MDYwMDAwIHJldj0weDAxIGhkcj0weDAwIHZlbmRv cj0weDgwODYgZGV2aWNlPTB4OWExNCBzdWJ2ZW5kb3I9MHgxMDNjIHN1YmRldmljZT0weDg3MDkK ICAgIHZlbmRvciAgICAgPSAnSW50ZWwgQ29ycG9yYXRpb24nCiAgICBkZXZpY2UgICAgID0gJzEx dGggR2VuIENvcmUgUHJvY2Vzc29yIEhvc3QgQnJpZGdlL0RSQU0gUmVnaXN0ZXJzJwogICAgY2xh c3MgICAgICA9IGJyaWRnZQogICAgc3ViY2xhc3MgICA9IEhPU1QtUENJCnZnYXBjaTBAcGNpMDow OjI6MDoJY2xhc3M9MHgwMzAwMDAgcmV2PTB4MDEgaGRyPTB4MDAgdmVuZG9yPTB4ODA4NiBkZXZp Y2U9MHg5YTQ5IHN1YnZlbmRvcj0weDEwM2Mgc3ViZGV2aWNlPTB4ODcwOQogICAgdmVuZG9yICAg ICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGRldmljZSAgICAgPSAnVUhEIEdyYXBoaWNzJwog ICAgY2xhc3MgICAgICA9IGRpc3BsYXkKICAgIHN1YmNsYXNzICAgPSBWR0EKbm9uZTBAcGNpMDow OjQ6MDoJY2xhc3M9MHgxMTgwMDAgcmV2PTB4MDEgaGRyPTB4MDAgdmVuZG9yPTB4ODA4NiBkZXZp Y2U9MHg5YTAzIHN1YnZlbmRvcj0weDEwM2Mgc3ViZGV2aWNlPTB4ODcwOQogICAgdmVuZG9yICAg ICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGNsYXNzICAgICAgPSBkYXNwCnBjaWIxQHBjaTA6 MDo3OjA6CWNsYXNzPTB4MDYwNDAwIHJldj0weDAxIGhkcj0weDAxIHZlbmRvcj0weDgwODYgZGV2 aWNlPTB4OWEyMyBzdWJ2ZW5kb3I9MHgxMDNjIHN1YmRldmljZT0weDg3MDkKICAgIHZlbmRvciAg ICAgPSAnSW50ZWwgQ29ycG9yYXRpb24nCiAgICBkZXZpY2UgICAgID0gJ1RpZ2VyIExha2UtTFAg VGh1bmRlcmJvbHQgUENJIEV4cHJlc3MgUm9vdCBQb3J0JwogICAgY2xhc3MgICAgICA9IGJyaWRn ZQogICAgc3ViY2xhc3MgICA9IFBDSS1QQ0kKcGNpYjJAcGNpMDowOjc6MToJY2xhc3M9MHgwNjA0 MDAgcmV2PTB4MDEgaGRyPTB4MDEgdmVuZG9yPTB4ODA4NiBkZXZpY2U9MHg5YTI1IHN1YnZlbmRv cj0weDEwM2Mgc3ViZGV2aWNlPTB4ODcwOQogICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3Jh dGlvbicKICAgIGRldmljZSAgICAgPSAnVGlnZXIgTGFrZS1MUCBUaHVuZGVyYm9sdCBQQ0kgRXhw cmVzcyBSb290IFBvcnQnCiAgICBjbGFzcyAgICAgID0gYnJpZGdlCiAgICBzdWJjbGFzcyAgID0g UENJLVBDSQpub25lMUBwY2kwOjA6ODowOgljbGFzcz0weDA4ODAwMCByZXY9MHgwMSBoZHI9MHgw MCB2ZW5kb3I9MHg4MDg2IGRldmljZT0weDlhMTEgc3VidmVuZG9yPTB4MTAzYyBzdWJkZXZpY2U9 MHg4NzA5CiAgICB2ZW5kb3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAgY2xhc3MgICAg ICA9IGJhc2UgcGVyaXBoZXJhbAp4aGNpMEBwY2kwOjA6MTM6MDoJY2xhc3M9MHgwYzAzMzAgcmV2 PTB4MDEgaGRyPTB4MDAgdmVuZG9yPTB4ODA4NiBkZXZpY2U9MHg5YTEzIHN1YnZlbmRvcj0weDEw M2Mgc3ViZGV2aWNlPTB4ODcwOQogICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicK ICAgIGRldmljZSAgICAgPSAnVGlnZXIgTGFrZS1MUCBUaHVuZGVyYm9sdCBVU0IgQ29udHJvbGxl cicKICAgIGNsYXNzICAgICAgPSBzZXJpYWwgYnVzCiAgICBzdWJjbGFzcyAgID0gVVNCCm5vbmUy QHBjaTA6MDoxMzoyOgljbGFzcz0weDBjMDM0MCByZXY9MHgwMSBoZHI9MHgwMCB2ZW5kb3I9MHg4 MDg2IGRldmljZT0weDlhMWIgc3VidmVuZG9yPTB4MDAwMCBzdWJkZXZpY2U9MHgwMDAwCiAgICB2 ZW5kb3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAgZGV2aWNlICAgICA9ICdUaWdlciBM YWtlLUxQIFRodW5kZXJib2x0IE5ISScKICAgIGNsYXNzICAgICAgPSBzZXJpYWwgYnVzCiAgICBz dWJjbGFzcyAgID0gVVNCCm5vbmUzQHBjaTA6MDoxNDowOgljbGFzcz0weDAxMDQwMCByZXY9MHgw MCBoZHI9MHgwMCB2ZW5kb3I9MHg4MDg2IGRldmljZT0weDlhMGIgc3VidmVuZG9yPTB4ODA4NiBz dWJkZXZpY2U9MHgwMDAwCiAgICB2ZW5kb3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAg ZGV2aWNlICAgICA9ICdWb2x1bWUgTWFuYWdlbWVudCBEZXZpY2UgTlZNZSBSQUlEIENvbnRyb2xs ZXInCiAgICBjbGFzcyAgICAgID0gbWFzcyBzdG9yYWdlCiAgICBzdWJjbGFzcyAgID0gUkFJRApu b25lNEBwY2kwOjA6MTg6MDoJY2xhc3M9MHgwNzAwMDAgcmV2PTB4MjAgaGRyPTB4MDAgdmVuZG9y PTB4ODA4NiBkZXZpY2U9MHhhMGZjIHN1YnZlbmRvcj0weDEwM2Mgc3ViZGV2aWNlPTB4ODcwOQog ICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGRldmljZSAgICAgPSAnVGln ZXIgTGFrZS1MUCBJbnRlZ3JhdGVkIFNlbnNvciBIdWInCiAgICBjbGFzcyAgICAgID0gc2ltcGxl IGNvbW1zCiAgICBzdWJjbGFzcyAgID0gVUFSVAp4aGNpMUBwY2kwOjA6MjA6MDoJY2xhc3M9MHgw YzAzMzAgcmV2PTB4MjAgaGRyPTB4MDAgdmVuZG9yPTB4ODA4NiBkZXZpY2U9MHhhMGVkIHN1YnZl bmRvcj0weDEwM2Mgc3ViZGV2aWNlPTB4ODcwOQogICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jw b3JhdGlvbicKICAgIGRldmljZSAgICAgPSAnVGlnZXIgTGFrZS1MUCBVU0IgMy4yIEdlbiAyeDEg eEhDSSBIb3N0IENvbnRyb2xsZXInCiAgICBjbGFzcyAgICAgID0gc2VyaWFsIGJ1cwogICAgc3Vi Y2xhc3MgICA9IFVTQgpub25lNUBwY2kwOjA6MjA6MjoJY2xhc3M9MHgwNTAwMDAgcmV2PTB4MjAg aGRyPTB4MDAgdmVuZG9yPTB4ODA4NiBkZXZpY2U9MHhhMGVmIHN1YnZlbmRvcj0weDEwM2Mgc3Vi ZGV2aWNlPTB4ODcwOQogICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGRl dmljZSAgICAgPSAnVGlnZXIgTGFrZS1MUCBTaGFyZWQgU1JBTScKICAgIGNsYXNzICAgICAgPSBt ZW1vcnkKICAgIHN1YmNsYXNzICAgPSBSQU0Kbm9uZTZAcGNpMDowOjIwOjM6CWNsYXNzPTB4MDI4 MDAwIHJldj0weDIwIGhkcj0weDAwIHZlbmRvcj0weDgwODYgZGV2aWNlPTB4YTBmMCBzdWJ2ZW5k b3I9MHg4MDg2IHN1YmRldmljZT0weDAwNzQKICAgIHZlbmRvciAgICAgPSAnSW50ZWwgQ29ycG9y YXRpb24nCiAgICBkZXZpY2UgICAgID0gJ1dpLUZpIDYgQVgyMDEnCiAgICBjbGFzcyAgICAgID0g bmV0d29yawppZzRpaWMwQHBjaTA6MDoyMTowOgljbGFzcz0weDBjODAwMCByZXY9MHgyMCBoZHI9 MHgwMCB2ZW5kb3I9MHg4MDg2IGRldmljZT0weGEwZTggc3VidmVuZG9yPTB4MTAzYyBzdWJkZXZp Y2U9MHg4NzA5CiAgICB2ZW5kb3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAgZGV2aWNl ICAgICA9ICdUaWdlciBMYWtlLUxQIFNlcmlhbCBJTyBJMkMgQ29udHJvbGxlcicKICAgIGNsYXNz ICAgICAgPSBzZXJpYWwgYnVzCmlnNGlpYzFAcGNpMDowOjIxOjE6CWNsYXNzPTB4MGM4MDAwIHJl dj0weDIwIGhkcj0weDAwIHZlbmRvcj0weDgwODYgZGV2aWNlPTB4YTBlOSBzdWJ2ZW5kb3I9MHgx MDNjIHN1YmRldmljZT0weDg3MDkKICAgIHZlbmRvciAgICAgPSAnSW50ZWwgQ29ycG9yYXRpb24n CiAgICBkZXZpY2UgICAgID0gJ1RpZ2VyIExha2UtTFAgU2VyaWFsIElPIEkyQyBDb250cm9sbGVy JwogICAgY2xhc3MgICAgICA9IHNlcmlhbCBidXMKbm9uZTdAcGNpMDowOjIyOjA6CWNsYXNzPTB4 MDc4MDAwIHJldj0weDIwIGhkcj0weDAwIHZlbmRvcj0weDgwODYgZGV2aWNlPTB4YTBlMCBzdWJ2 ZW5kb3I9MHgxMDNjIHN1YmRldmljZT0weDg3MDkKICAgIHZlbmRvciAgICAgPSAnSW50ZWwgQ29y cG9yYXRpb24nCiAgICBkZXZpY2UgICAgID0gJ1RpZ2VyIExha2UtTFAgTWFuYWdlbWVudCBFbmdp bmUgSW50ZXJmYWNlJwogICAgY2xhc3MgICAgICA9IHNpbXBsZSBjb21tcwpwY2liM0BwY2kwOjA6 Mjg6MDoJY2xhc3M9MHgwNjA0MDAgcmV2PTB4MjAgaGRyPTB4MDEgdmVuZG9yPTB4ODA4NiBkZXZp Y2U9MHhhMGJkIHN1YnZlbmRvcj0weDEwM2Mgc3ViZGV2aWNlPTB4ODcwOQogICAgdmVuZG9yICAg ICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGNsYXNzICAgICAgPSBicmlkZ2UKICAgIHN1YmNs YXNzICAgPSBQQ0ktUENJCm5vbmU4QHBjaTA6MDoyOTowOgljbGFzcz0weDA4ODAwMCByZXY9MHgw MCBoZHI9MHgwMCB2ZW5kb3I9MHg4MDg2IGRldmljZT0weDA5YWIgc3VidmVuZG9yPTB4MTAzYyBz dWJkZXZpY2U9MHg4NzA5CiAgICB2ZW5kb3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAg Y2xhc3MgICAgICA9IGJhc2UgcGVyaXBoZXJhbAppc2FiMEBwY2kwOjA6MzE6MDoJY2xhc3M9MHgw NjAxMDAgcmV2PTB4MjAgaGRyPTB4MDAgdmVuZG9yPTB4ODA4NiBkZXZpY2U9MHhhMDgyIHN1YnZl bmRvcj0weDEwM2Mgc3ViZGV2aWNlPTB4ODcwOQogICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jw b3JhdGlvbicKICAgIGRldmljZSAgICAgPSAnVGlnZXIgTGFrZS1MUCBMUEMgQ29udHJvbGxlcicK ICAgIGNsYXNzICAgICAgPSBicmlkZ2UKICAgIHN1YmNsYXNzICAgPSBQQ0ktSVNBCmhkYWMwQHBj aTA6MDozMTozOgljbGFzcz0weDA0MDEwMCByZXY9MHgyMCBoZHI9MHgwMCB2ZW5kb3I9MHg4MDg2 IGRldmljZT0weGEwYzggc3VidmVuZG9yPTB4MTAzYyBzdWJkZXZpY2U9MHg4NzA5CiAgICB2ZW5k b3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAgZGV2aWNlICAgICA9ICdUaWdlciBMYWtl LUxQIFNtYXJ0IFNvdW5kIFRlY2hub2xvZ3kgQXVkaW8gQ29udHJvbGxlcicKICAgIGNsYXNzICAg ICAgPSBtdWx0aW1lZGlhCiAgICBzdWJjbGFzcyAgID0gYXVkaW8KaWNoc21iMEBwY2kwOjA6MzE6 NDoJY2xhc3M9MHgwYzA1MDAgcmV2PTB4MjAgaGRyPTB4MDAgdmVuZG9yPTB4ODA4NiBkZXZpY2U9 MHhhMGEzIHN1YnZlbmRvcj0weDEwM2Mgc3ViZGV2aWNlPTB4ODcwOQogICAgdmVuZG9yICAgICA9 ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGRldmljZSAgICAgPSAnVGlnZXIgTGFrZS1MUCBTTUJ1 cyBDb250cm9sbGVyJwogICAgY2xhc3MgICAgICA9IHNlcmlhbCBidXMKICAgIHN1YmNsYXNzICAg PSBTTUJ1cwpub25lOUBwY2kwOjA6MzE6NToJY2xhc3M9MHgwYzgwMDAgcmV2PTB4MjAgaGRyPTB4 MDAgdmVuZG9yPTB4ODA4NiBkZXZpY2U9MHhhMGE0IHN1YnZlbmRvcj0weDEwM2Mgc3ViZGV2aWNl PTB4ODcwOQogICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGRldmljZSAg ICAgPSAnVGlnZXIgTGFrZS1MUCBTUEkgQ29udHJvbGxlcicKICAgIGNsYXNzICAgICAgPSBzZXJp YWwgYnVzCnJ0c3gwQHBjaTA6ODc6MDowOgljbGFzcz0weGZmMDAwMCByZXY9MHgwMSBoZHI9MHgw MCB2ZW5kb3I9MHgxMGVjIGRldmljZT0weDUyNWEgc3VidmVuZG9yPTB4MTAzYyBzdWJkZXZpY2U9 MHg4NzA5CiAgICB2ZW5kb3IgICAgID0gJ1JlYWx0ZWsgU2VtaWNvbmR1Y3RvciBDby4sIEx0ZC4n CiAgICBkZXZpY2UgICAgID0gJ1JUUzUyNUEgUENJIEV4cHJlc3MgQ2FyZCBSZWFkZXInCg== --=_2d58dca25f95ab28b533ae54b1567b6b Content-Transfer-Encoding: base64 Content-Type: text/plain; name=acpidump.txt Content-Disposition: attachment; filename=acpidump.txt; size=10947 LyoKICBSU0QgUFRSOiBPRU09SFBRT0VNLCBBQ1BJX1Jldj0yLjB4ICgyKQoJWFNEVD0weDAwMDAw MDAwNTRkYmI3MjgsIGxlbmd0aD0zNiwgY2tzdW09MjA2CiAqLwovKgogIFhTRFQ6IExlbmd0aD0y NzYsIFJldmlzaW9uPTEsIENoZWNrc3VtPTU0LAoJT0VNSUQ9SFBRT0VNLCBPRU0gVGFibGUgSUQ9 U0xJQy1NUEMsIE9FTSBSZXZpc2lvbj0weDEwNzIwMDksCglDcmVhdG9yIElEPUFNSSwgQ3JlYXRv ciBSZXZpc2lvbj0weDEwMDAwMTMKCUVudHJpZXM9eyAweDAwMDAwMDAwNTRkYjYwMDAsIDB4MDAw MDAwMDA1NGRiYTAwMCwgMHgwMDAwMDAwMDU0ZGI3MDAwLCAweDAwMDAwMDAwNTRkNjEwMDAsIDB4 MDAwMDAwMDA1NGQ2MDAwMCwgMHgwMDAwMDAwMDU0ZDVjMDAwLCAweDAwMDAwMDAwNTRkNTUwMDAs IDB4MDAwMDAwMDA1NGQ0ODAwMCwgMHgwMDAwMDAwMDU0ZDQ3MDAwLCAweDAwMDAwMDAwNTRkNDUw MDAsIDB4MDAwMDAwMDA1NGQ0NDAwMCwgMHgwMDAwMDAwMDU0ZDQwMDAwLCAweDAwMDAwMDAwNTRk M2YwMDAsIDB4MDAwMDAwMDA1NGQzZTAwMCwgMHgwMDAwMDAwMDU0ZDNkMDAwLCAweDAwMDAwMDAw NTRkM2MwMDAsIDB4MDAwMDAwMDA1NGQzYjAwMCwgMHgwMDAwMDAwMDU0ZDNhMDAwLCAweDAwMDAw MDAwNTRkMzkwMDAsIDB4MDAwMDAwMDA1NGQzODAwMCwgMHgwMDAwMDAwMDU0ZDM3MDAwLCAweDAw MDAwMDAwNTRkZTYwMDAsIDB4MDAwMDAwMDA1NGRlNTAwMCwgMHgwMDAwMDAwMDU0ZDM2MDAwLCAw eDAwMDAwMDAwNTRkNDkwMDAsIDB4MDAwMDAwMDA1NGQ1OTAwMCwgMHgwMDAwMDAwMDU0ZDM1MDAw LCAweDAwMDAwMDAwNTRkNDMwMDAsIDB4MDAwMDAwMDA1NGQzNDAwMCwgMHgwMDAwMDAwMDU0ZDMz MDAwIH0KICovCi8qCiAgRkFDUDogTGVuZ3RoPTI3NiwgUmV2aXNpb249NiwgQ2hlY2tzdW09MTYz LAoJT0VNSUQ9SFBRT0VNLCBPRU0gVGFibGUgSUQ9U0xJQy1NUEMsIE9FTSBSZXZpc2lvbj0weDEw NzIwMDksCglDcmVhdG9yIElEPUhQLCBDcmVhdG9yIFJldmlzaW9uPTB4MTAwMTMKIAlGQUNTPTB4 NTRlNzcwMDAsIERTRFQ9MHg1NGQ2MjAwMAoJSU5UX01PREVMPVBJQwoJUHJlZmVycmVkX1BNX1By b2ZpbGU9TW9iaWxlICgyKQoJU0NJX0lOVD05CglTTUlfQ01EPTB4YjIsIEFDUElfRU5BQkxFPTB4 YTAsIEFDUElfRElTQUJMRT0weGExLCBTNEJJT1NfUkVRPTB4MAoJUFNUQVRFX0NOVD0weDAKCVBN MWFfRVZUX0JMSz0weDE4MDAtMHgxODAzCglQTTFhX0NOVF9CTEs9MHgxODA0LTB4MTgwNQoJUE0y X0NOVF9CTEs9MHgxODUwLTB4MTg1MAoJUE1fVE1SX0JMSz0weDE4MDgtMHgxODBiCglHUEUwX0JM Sz0weDE4NjAtMHgxODdmCglQX0xWTDJfTEFUPTEwMSB1cywgUF9MVkwzX0xBVD0xMDAxIHVzCglG TFVTSF9TSVpFPTEwMjQsIEZMVVNIX1NUUklERT0xNgoJRFVUWV9PRkZTRVQ9MSwgRFVUWV9XSURU SD0zCglEQVlfQUxSTT0xMywgTU9OX0FMUk09MCwgQ0VOVFVSWT01MAoJSUFQQ19CT09UX0FSQ0g9 ezgwNDIsTk9fQVNQTX0KCUZsYWdzPXtXQklOVkQsQzFfU1VQUE9SVEVELFNMRUVQX0JVVFRPTixT NF9SVENfV0FLRSxSRVNFVF9SRUdJU1RFUixQQ0lfRVhQUkVTU19XQUtFLFBMQVRGT1JNX0NMT0NL LFM0X1JUQ19WQUxJRCxSRU1PVEVfUE9XRVJfT04sTE9XX1BPV0VSX1MwfQoJUkVTRVRfUkVHPTB4 YjI6MFs4XSAoSU8pLCBSRVNFVF9WQUxVRT0weGViCiAqLwovKgogIEZBQ1M6CUxlbmd0aD02NCwg SHdTaWc9MHhjMGYxYmUyZiwgRmlybV9XYWtlX1ZlYz0weDAwMDAwMDAwCglHbG9iYWxfTG9jaz0K CUZsYWdzPQoJVmVyc2lvbj0yCiAqLwovKgogIERTRFQ6IExlbmd0aD0zNDE5MjQsIFJldmlzaW9u PTIsIENoZWNrc3VtPTE5NywKCU9FTUlEPUhQUU9FTSwgT0VNIFRhYmxlIElEPTg3MDksIE9FTSBS ZXZpc2lvbj0weDEwNzIwMDksCglDcmVhdG9yIElEPUFDUEksIENyZWF0b3IgUmV2aXNpb249MHgy MDE5MTAxOAogKi8KLyoKICBNQ0ZHOiBMZW5ndGg9NjAsIFJldmlzaW9uPTEsIENoZWNrc3VtPTM3 LAoJT0VNSUQ9SFBRT0VNLCBPRU0gVGFibGUgSUQ9ODcwOSwgT0VNIFJldmlzaW9uPTB4MTA3MjAw OSwKCUNyZWF0b3IgSUQ9SFAsIENyZWF0b3IgUmV2aXNpb249MHg5NwoKCUJhc2UgQWRkcmVzcz0w eDAwMDAwMDAwYzAwMDAwMDAKCVNlZ21lbnQgR3JvdXA9MHgwMDAwCglTdGFydCBCdXM9MAoJRW5k IEJ1cz0yNTUKICovCi8qCiAgU1NEVDogTGVuZ3RoPTk2NzksIFJldmlzaW9uPTIsIENoZWNrc3Vt PTczLAoJT0VNSUQ9SFBRT0VNLCBPRU0gVGFibGUgSUQ9ODcwOSwgT0VNIFJldmlzaW9uPTB4MzAw MCwKCUNyZWF0b3IgSUQ9QUNQSSwgQ3JlYXRvciBSZXZpc2lvbj0weDIwMTkxMDE4CiAqLwovKgog IEZJRFQ6IExlbmd0aD0xNTYsIFJldmlzaW9uPTEsIENoZWNrc3VtPTIxMCwKCU9FTUlEPUhQUU9F TSwgT0VNIFRhYmxlIElEPTg3MDksIE9FTSBSZXZpc2lvbj0weDEwNzIwMDksCglDcmVhdG9yIElE PUhQLCBDcmVhdG9yIFJldmlzaW9uPTB4MTAwMTMKICovCi8qCiAgTVNETTogTGVuZ3RoPTg1LCBS ZXZpc2lvbj0zLCBDaGVja3N1bT0xOTYsCglPRU1JRD1IUFFPRU0sIE9FTSBUYWJsZSBJRD1TTElD LU1QQywgT0VNIFJldmlzaW9uPTB4MSwKCUNyZWF0b3IgSUQ9SFAsIENyZWF0b3IgUmV2aXNpb249 MHgxMDAxMwogKi8KLyoKICBTU0RUOiBMZW5ndGg9MTMwNTYsIFJldmlzaW9uPTIsIENoZWNrc3Vt PTEwNywKCU9FTUlEPUhQUU9FTSwgT0VNIFRhYmxlIElEPTg3MDksIE9FTSBSZXZpc2lvbj0weDEw MDAsCglDcmVhdG9yIElEPUFDUEksIENyZWF0b3IgUmV2aXNpb249MHgyMDE5MTAxOAogKi8KLyoK ICBTU0RUOiBMZW5ndGg9MTMxMzYsIFJldmlzaW9uPTIsIENoZWNrc3VtPTQxLAoJT0VNSUQ9SFBR T0VNLCBPRU0gVGFibGUgSUQ9ODcwOSwgT0VNIFJldmlzaW9uPTB4MzAwMCwKCUNyZWF0b3IgSUQ9 QUNQSSwgQ3JlYXRvciBSZXZpc2lvbj0weDIwMTkxMDE4CiAqLwovKgogIEhQRVQ6IExlbmd0aD01 NiwgUmV2aXNpb249MSwgQ2hlY2tzdW09MzIsCglPRU1JRD1IUFFPRU0sIE9FTSBUYWJsZSBJRD04 NzA5LCBPRU0gUmV2aXNpb249MHgxMDcyMDA5LAoJQ3JlYXRvciBJRD1IUCwgQ3JlYXRvciBSZXZp c2lvbj0weDEwMDAwMTMKCUhQRVQgTnVtYmVyPTAKCUFERFI9MHgwMDAwMDAwMGZlZDAwMDAwOjBb NjRdIChNZW1vcnkpCglIVyBSZXY9MHgxCglDb21wYXJhdG9ycz0yCglDb3VudGVyIFNpemU9MQoJ TGVnYWN5IElSUSByb3V0aW5nIGNhcGFibGU9e1RSVUV9CglQQ0kgVmVuZG9yIElEPTB4ODA4NgoJ TWluaW1hbCBUaWNrPTEyOAoJRmxhZ3M9MHgwMAogKi8KLyoKICBBUElDOiBMZW5ndGg9MzAwLCBS ZXZpc2lvbj00LCBDaGVja3N1bT0yNDIsCglPRU1JRD1IUFFPRU0sIE9FTSBUYWJsZSBJRD04NzA5 LCBPRU0gUmV2aXNpb249MHgxMDcyMDA5LAoJQ3JlYXRvciBJRD1IUCwgQ3JlYXRvciBSZXZpc2lv bj0weDEwMDAwMTMKCUxvY2FsIEFQSUMgQUREUj0weGZlZTAwMDAwCglGbGFncz17UEMtQVR9CgoJ VHlwZT1Mb2NhbCBBUElDCglBQ1BJIENQVT0wCglGbGFncz17RU5BQkxFRH0KCUFQSUMgSUQ9MAoK CVR5cGU9TG9jYWwgQVBJQwoJQUNQSSBDUFU9MQoJRmxhZ3M9e0VOQUJMRUR9CglBUElDIElEPTIK CglUeXBlPUxvY2FsIEFQSUMKCUFDUEkgQ1BVPTIKCUZsYWdzPXtFTkFCTEVEfQoJQVBJQyBJRD00 CgoJVHlwZT1Mb2NhbCBBUElDCglBQ1BJIENQVT0zCglGbGFncz17RU5BQkxFRH0KCUFQSUMgSUQ9 NgoKCVR5cGU9TG9jYWwgQVBJQwoJQUNQSSBDUFU9NAoJRmxhZ3M9e0VOQUJMRUR9CglBUElDIElE PTEKCglUeXBlPUxvY2FsIEFQSUMKCUFDUEkgQ1BVPTUKCUZsYWdzPXtFTkFCTEVEfQoJQVBJQyBJ RD0zCgoJVHlwZT1Mb2NhbCBBUElDCglBQ1BJIENQVT02CglGbGFncz17RU5BQkxFRH0KCUFQSUMg SUQ9NQoKCVR5cGU9TG9jYWwgQVBJQwoJQUNQSSBDUFU9NwoJRmxhZ3M9e0VOQUJMRUR9CglBUElD IElEPTcKCglUeXBlPUxvY2FsIEFQSUMKCUFDUEkgQ1BVPTgKCUZsYWdzPXtESVNBQkxFRH0KCUFQ SUMgSUQ9MjU1CgoJVHlwZT1Mb2NhbCBBUElDCglBQ1BJIENQVT05CglGbGFncz17RElTQUJMRUR9 CglBUElDIElEPTI1NQoKCVR5cGU9TG9jYWwgQVBJQwoJQUNQSSBDUFU9MTAKCUZsYWdzPXtESVNB QkxFRH0KCUFQSUMgSUQ9MjU1CgoJVHlwZT1Mb2NhbCBBUElDCglBQ1BJIENQVT0xMQoJRmxhZ3M9 e0RJU0FCTEVEfQoJQVBJQyBJRD0yNTUKCglUeXBlPUxvY2FsIEFQSUMKCUFDUEkgQ1BVPTEyCglG bGFncz17RElTQUJMRUR9CglBUElDIElEPTI1NQoKCVR5cGU9TG9jYWwgQVBJQwoJQUNQSSBDUFU9 MTMKCUZsYWdzPXtESVNBQkxFRH0KCUFQSUMgSUQ9MjU1CgoJVHlwZT1Mb2NhbCBBUElDCglBQ1BJ IENQVT0xNAoJRmxhZ3M9e0RJU0FCTEVEfQoJQVBJQyBJRD0yNTUKCglUeXBlPUxvY2FsIEFQSUMK CUFDUEkgQ1BVPTE1CglGbGFncz17RElTQUJMRUR9CglBUElDIElEPTI1NQoKCVR5cGU9SU8gQVBJ QwoJQVBJQyBJRD0yCglJTlQgQkFTRT0wCglBRERSPTB4MDAwMDAwMDBmZWMwMDAwMAoKCVR5cGU9 SU5UIE92ZXJyaWRlCglCVVM9MAoJSVJRPTAKCUlOVFI9MgoJRmxhZ3M9e1BvbGFyaXR5PWNvbmZv cm1pbmcsIFRyaWdnZXI9Y29uZm9ybWluZ30KCglUeXBlPUlOVCBPdmVycmlkZQoJQlVTPTAKCUlS UT05CglJTlRSPTkKCUZsYWdzPXtQb2xhcml0eT1hY3RpdmUtaGksIFRyaWdnZXI9bGV2ZWx9CgoJ VHlwZT1Mb2NhbCBBUElDIE5NSQoJQUNQSSBDUFU9MQoJTElOVCBQaW49MQoJRmxhZ3M9e1BvbGFy aXR5PWFjdGl2ZS1oaSwgVHJpZ2dlcj1lZGdlfQoKCVR5cGU9TG9jYWwgQVBJQyBOTUkKCUFDUEkg Q1BVPTIKCUxJTlQgUGluPTEKCUZsYWdzPXtQb2xhcml0eT1hY3RpdmUtaGksIFRyaWdnZXI9ZWRn ZX0KCglUeXBlPUxvY2FsIEFQSUMgTk1JCglBQ1BJIENQVT0zCglMSU5UIFBpbj0xCglGbGFncz17 UG9sYXJpdHk9YWN0aXZlLWhpLCBUcmlnZ2VyPWVkZ2V9CgoJVHlwZT1Mb2NhbCBBUElDIE5NSQoJ QUNQSSBDUFU9NAoJTElOVCBQaW49MQoJRmxhZ3M9e1BvbGFyaXR5PWFjdGl2ZS1oaSwgVHJpZ2dl cj1lZGdlfQoKCVR5cGU9TG9jYWwgQVBJQyBOTUkKCUFDUEkgQ1BVPTUKCUxJTlQgUGluPTEKCUZs YWdzPXtQb2xhcml0eT1hY3RpdmUtaGksIFRyaWdnZXI9ZWRnZX0KCglUeXBlPUxvY2FsIEFQSUMg Tk1JCglBQ1BJIENQVT02CglMSU5UIFBpbj0xCglGbGFncz17UG9sYXJpdHk9YWN0aXZlLWhpLCBU cmlnZ2VyPWVkZ2V9CgoJVHlwZT1Mb2NhbCBBUElDIE5NSQoJQUNQSSBDUFU9NwoJTElOVCBQaW49 MQoJRmxhZ3M9e1BvbGFyaXR5PWFjdGl2ZS1oaSwgVHJpZ2dlcj1lZGdlfQoKCVR5cGU9TG9jYWwg QVBJQyBOTUkKCUFDUEkgQ1BVPTgKCUxJTlQgUGluPTEKCUZsYWdzPXtQb2xhcml0eT1hY3RpdmUt aGksIFRyaWdnZXI9ZWRnZX0KCglUeXBlPUxvY2FsIEFQSUMgTk1JCglBQ1BJIENQVT05CglMSU5U IFBpbj0xCglGbGFncz17UG9sYXJpdHk9YWN0aXZlLWhpLCBUcmlnZ2VyPWVkZ2V9CgoJVHlwZT1M b2NhbCBBUElDIE5NSQoJQUNQSSBDUFU9MTAKCUxJTlQgUGluPTEKCUZsYWdzPXtQb2xhcml0eT1h Y3RpdmUtaGksIFRyaWdnZXI9ZWRnZX0KCglUeXBlPUxvY2FsIEFQSUMgTk1JCglBQ1BJIENQVT0x MQoJTElOVCBQaW49MQoJRmxhZ3M9e1BvbGFyaXR5PWFjdGl2ZS1oaSwgVHJpZ2dlcj1lZGdlfQoK CVR5cGU9TG9jYWwgQVBJQyBOTUkKCUFDUEkgQ1BVPTEyCglMSU5UIFBpbj0xCglGbGFncz17UG9s YXJpdHk9YWN0aXZlLWhpLCBUcmlnZ2VyPWVkZ2V9CgoJVHlwZT1Mb2NhbCBBUElDIE5NSQoJQUNQ SSBDUFU9MTMKCUxJTlQgUGluPTEKCUZsYWdzPXtQb2xhcml0eT1hY3RpdmUtaGksIFRyaWdnZXI9 ZWRnZX0KCglUeXBlPUxvY2FsIEFQSUMgTk1JCglBQ1BJIENQVT0xNAoJTElOVCBQaW49MQoJRmxh Z3M9e1BvbGFyaXR5PWFjdGl2ZS1oaSwgVHJpZ2dlcj1lZGdlfQoKCVR5cGU9TG9jYWwgQVBJQyBO TUkKCUFDUEkgQ1BVPTE1CglMSU5UIFBpbj0xCglGbGFncz17UG9sYXJpdHk9YWN0aXZlLWhpLCBU cmlnZ2VyPWVkZ2V9CgoJVHlwZT1Mb2NhbCBBUElDIE5NSQoJQUNQSSBDUFU9MTYKCUxJTlQgUGlu PTEKCUZsYWdzPXtQb2xhcml0eT1hY3RpdmUtaGksIFRyaWdnZXI9ZWRnZX0KICovCi8qCiAgTkhM VDogTGVuZ3RoPTcwNDQsIFJldmlzaW9uPTAsIENoZWNrc3VtPTExMywKCU9FTUlEPUhQUU9FTSwg T0VNIFRhYmxlIElEPTg3MDksIE9FTSBSZXZpc2lvbj0weDEwNzIwMDksCglDcmVhdG9yIElEPUhQ LCBDcmVhdG9yIFJldmlzaW9uPTB4MTAwMDAxMwogKi8KLyoKICBMUElUOiBMZW5ndGg9MjA0LCBS ZXZpc2lvbj0xLCBDaGVja3N1bT0xMjUsCglPRU1JRD1IUFFPRU0sIE9FTSBUYWJsZSBJRD04NzA5 LCBPRU0gUmV2aXNpb249MHgxMDcyMDA5LAoJQ3JlYXRvciBJRD1IUCwgQ3JlYXRvciBSZXZpc2lv bj0weDEwMDAwMTMKCglUeXBlPUFDUElfTFBJVF9UWVBFX05BVElWRV9DU1RBVEUKCUxlbmd0aD01 NgoJVW5pcXVlSWQ9MHgwMDAwCglGbGFncz0KCUVudHJ5VHJpZ2dlcj0weDAwMDAwMDAwMDAwMDAw NjAgKD8pCglSZXNpZGVuY3k9MzAwMDAKCUxhdGVuY3k9MzAwMAoJUmVzaWRlbmN5Q291bnRlcj0w eDAwMDAwMDAwMDAwMDA2MzIgKD8pCglDb3VudGVyRnJlcXVlbmN5PVRTQwoKCVR5cGU9QUNQSV9M UElUX1RZUEVfTkFUSVZFX0NTVEFURQoJTGVuZ3RoPTU2CglVbmlxdWVJZD0weDAwMDEKCUZsYWdz PQoJRW50cnlUcmlnZ2VyPTB4MDAwMDAwMDAwMDAwMDA2MCAoPykKCVJlc2lkZW5jeT0zMDAwMAoJ TGF0ZW5jeT0zMDAwCglSZXNpZGVuY3lDb3VudGVyPTB4MDAwMDAwMDBmZTAwMTkzYzowWzMyXSAo TWVtb3J5KQoJQ291bnRlckZyZXF1ZW5jeT04MTk3CgoJVHlwZT1BQ1BJX0xQSVRfVFlQRV9OQVRJ VkVfQ1NUQVRFCglMZW5ndGg9NTYKCVVuaXF1ZUlkPTB4MDAwMgoJRmxhZ3M9e1NUQVRFX0RJU0FC TEVEfQoJRW50cnlUcmlnZ2VyPTB4MDAwMDAwMDAwMDAwMDA2MCAoPykKCVJlc2lkZW5jeT0zMDAw MAoJTGF0ZW5jeT0zMDAwCglSZXNpZGVuY3lDb3VudGVyPTB4MDAwMDAwMDAwMDAwMDBmZjowWzMy XSAoTWVtb3J5KQoJQ291bnRlckZyZXF1ZW5jeT1UU0MKICovCi8qCiAgU1NEVDogTGVuZ3RoPTEw MDE2LCBSZXZpc2lvbj0yLCBDaGVja3N1bT0zOCwKCU9FTUlEPUhQUU9FTSwgT0VNIFRhYmxlIElE PTg3MDksIE9FTSBSZXZpc2lvbj0weDEwMDAsCglDcmVhdG9yIElEPUFDUEksIENyZWF0b3IgUmV2 aXNpb249MHgyMDE5MTAxOAogKi8KLyoKICBTU0RUOiBMZW5ndGg9Mjk4LCBSZXZpc2lvbj0yLCBD aGVja3N1bT0yNDAsCglPRU1JRD1IUFFPRU0sIE9FTSBUYWJsZSBJRD04NzA5LCBPRU0gUmV2aXNp b249MHgwLAoJQ3JlYXRvciBJRD1BQ1BJLCBDcmVhdG9yIFJldmlzaW9uPTB4MjAxOTEwMTgKICov Ci8qCiAgREJHUDogTGVuZ3RoPTUyLCBSZXZpc2lvbj0xLCBDaGVja3N1bT0xNjgsCglPRU1JRD1I UFFPRU0sIE9FTSBUYWJsZSBJRD04NzA5LCBPRU0gUmV2aXNpb249MHgxMDcyMDA5LAoJQ3JlYXRv ciBJRD1IUCwgQ3JlYXRvciBSZXZpc2lvbj0weDEwMDAwMTMKICovCi8qCiAgREJHMjogTGVuZ3Ro PTg0LCBSZXZpc2lvbj0wLCBDaGVja3N1bT0yNDksCglPRU1JRD1IUFFPRU0sIE9FTSBUYWJsZSBJ RD04NzA5LCBPRU0gUmV2aXNpb249MHgxMDcyMDA5LAoJQ3JlYXRvciBJRD1IUCwgQ3JlYXRvciBS ZXZpc2lvbj0weDEwMDAwMTMKICovCi8qCiAgU1NEVDogTGVuZ3RoPTI5ODAsIFJldmlzaW9uPTIs IENoZWNrc3VtPTEwMCwKCU9FTUlEPUhQUU9FTSwgT0VNIFRhYmxlIElEPTg3MDksIE9FTSBSZXZp c2lvbj0weDEwMDAsCglDcmVhdG9yIElEPUFDUEksIENyZWF0b3IgUmV2aXNpb249MHgyMDE5MTAx OAogKi8KLyoKICBETUFSOiBMZW5ndGg9MTg0LCBSZXZpc2lvbj0yLCBDaGVja3N1bT0xOTEsCglP RU1JRD1IUFFPRU0sIE9FTSBUYWJsZSBJRD04NzA5LCBPRU0gUmV2aXNpb249MHgyLAoJQ3JlYXRv ciBJRD1IUCwgQ3JlYXRvciBSZXZpc2lvbj0weDEwMDAwMTMKCUhvc3QgQWRkcmVzcyBXaWR0aD0z OQoJRmxhZ3M9e0lOVFJfUkVNQVB9CgoJVHlwZT1EUkhECglMZW5ndGg9MjQKCUZsYWdzPQoJU2Vn bWVudD0wCglBZGRyZXNzPTB4MDAwMDAwMDBmZWQ5MDAwMAoJRGV2aWNlIFNjb3BlOgoJCVR5cGU9 UENJIEVuZHBvaW50IERldmljZQoJCUxlbmd0aD04CgkJRW51bWVyYXRpb25JZD0wCgkJU3RhcnRC dXNOdW1iZXI9MAoJCVBhdGg9ezI6MH0KCglUeXBlPURSSEQKCUxlbmd0aD0yNAoJRmxhZ3M9CglT ZWdtZW50PTAKCUFkZHJlc3M9MHgwMDAwMDAwMGZlZDg0MDAwCglEZXZpY2UgU2NvcGU6CgkJVHlw ZT1QQ0kgU3ViLUhpZXJhcmNoeQoJCUxlbmd0aD04CgkJRW51bWVyYXRpb25JZD0wCgkJU3RhcnRC dXNOdW1iZXI9MAoJCVBhdGg9ezc6MH0KCglUeXBlPURSSEQKCUxlbmd0aD0yNAoJRmxhZ3M9CglT ZWdtZW50PTAKCUFkZHJlc3M9MHgwMDAwMDAwMGZlZDg1MDAwCglEZXZpY2UgU2NvcGU6CgkJVHlw ZT1QQ0kgU3ViLUhpZXJhcmNoeQoJCUxlbmd0aD04CgkJRW51bWVyYXRpb25JZD0wCgkJU3RhcnRC dXNOdW1iZXI9MAoJCVBhdGg9ezc6MX0KCglUeXBlPURSSEQKCUxlbmd0aD0zMgoJRmxhZ3M9e0lO Q0xVREVfQUxMfQoJU2VnbWVudD0wCglBZGRyZXNzPTB4MDAwMDAwMDBmZWQ5MTAwMAoJRGV2aWNl IFNjb3BlOgoJCVR5cGU9SU9BUElDCgkJTGVuZ3RoPTgKCQlFbnVtZXJhdGlvbklkPTIKCQlTdGFy dEJ1c051bWJlcj0wCgkJUGF0aD17MzA6N30KCgkJVHlwZT1IUEVUCgkJTGVuZ3RoPTgKCQlFbnVt ZXJhdGlvbklkPTAKCQlTdGFydEJ1c051bWJlcj0wCgkJUGF0aD17MzA6Nn0KCglUeXBlPVJNUlIK CUxlbmd0aD0zMgoJU2VnbWVudD0wCglCYXNlQWRkcmVzcz0weDAwMDAwMDAwNjQwMDAwMDAKCUxp bWl0QWRkcmVzcz0weDAwMDAwMDAwNjgzZmZmZmYKCURldmljZSBTY29wZToKCQlUeXBlPVBDSSBF bmRwb2ludCBEZXZpY2UKCQlMZW5ndGg9OAoJCUVudW1lcmF0aW9uSWQ9MAoJCVN0YXJ0QnVzTnVt YmVyPTAKCQlQYXRoPXsyOjB9CiAqLwovKgogIFNTRFQ6IExlbmd0aD0xNjg1LCBSZXZpc2lvbj0y LCBDaGVja3N1bT0xNDMsCglPRU1JRD1IUFFPRU0sIE9FTSBUYWJsZSBJRD04NzA5LCBPRU0gUmV2 aXNpb249MHgwLAoJQ3JlYXRvciBJRD1BQ1BJLCBDcmVhdG9yIFJldmlzaW9uPTB4MjAxOTEwMTgK ICovCi8qCiAgU1NEVDogTGVuZ3RoPTMyNCwgUmV2aXNpb249MiwgQ2hlY2tzdW09ODYsCglPRU1J RD1IUFFPRU0sIE9FTSBUYWJsZSBJRD04NzA5LCBPRU0gUmV2aXNpb249MHgxMDAwLAoJQ3JlYXRv ciBJRD1BQ1BJLCBDcmVhdG9yIFJldmlzaW9uPTB4MjAxOTEwMTgKICovCi8qCiAgU1NEVDogTGVu Z3RoPTE1NywgUmV2aXNpb249MSwgQ2hlY2tzdW09NzEsCglPRU1JRD1IUFFPRU0sIE9FTSBUYWJs ZSBJRD04NzA5LCBPRU0gUmV2aXNpb249MHgxLAoJQ3JlYXRvciBJRD1BQ1BJLCBDcmVhdG9yIFJl dmlzaW9uPTB4MjAxOTEwMTgKICovCi8qCiAgU1NEVDogTGVuZ3RoPTk2LCBSZXZpc2lvbj0xLCBD aGVja3N1bT0yMjQsCglPRU1JRD1IUFFPRU0sIE9FTSBUYWJsZSBJRD04NzA5LCBPRU0gUmV2aXNp b249MHgxLAoJQ3JlYXRvciBJRD1BQ1BJLCBDcmVhdG9yIFJldmlzaW9uPTB4MjAxOTEwMTgKICov Ci8qCiAgVUVGSTogTGVuZ3RoPTE1OTQsIFJldmlzaW9uPTEsIENoZWNrc3VtPTE2OSwKCU9FTUlE PUhQUU9FTSwgT0VNIFRhYmxlIElEPTg3MDksIE9FTSBSZXZpc2lvbj0weDAsCglDcmVhdG9yIElE PUhQLCBDcmVhdG9yIFJldmlzaW9uPTB4MAogKi8KLyoKICBVRUZJOiBMZW5ndGg9OTIsIFJldmlz aW9uPTEsIENoZWNrc3VtPTg0LAoJT0VNSUQ9SFBRT0VNLCBPRU0gVGFibGUgSUQ9ODcwOSwgT0VN IFJldmlzaW9uPTB4MCwKCUNyZWF0b3IgSUQ9SFAsIENyZWF0b3IgUmV2aXNpb249MHgwCiAqLwov KgogIFRQTTI6IExlbmd0aD03NiwgUmV2aXNpb249NCwgQ2hlY2tzdW09MjQ1LAoJT0VNSUQ9SFBR T0VNLCBPRU0gVGFibGUgSUQ9ODcwOSwgT0VNIFJldmlzaW9uPTB4MSwKCUNyZWF0b3IgSUQ9SFAs IENyZWF0b3IgUmV2aXNpb249MHgwCgkJQ29udHJvbEFyZWE9MAoJCVN0YXJ0TWV0aG9kPTYKICov Ci8qCiAgU1NEVDogTGVuZ3RoPTQ1NTUyLCBSZXZpc2lvbj0yLCBDaGVja3N1bT0yMzEsCglPRU1J RD1IUFFPRU0sIE9FTSBUYWJsZSBJRD04NzA5LCBPRU0gUmV2aXNpb249MHgxMDAwLAoJQ3JlYXRv ciBJRD1BQ1BJLCBDcmVhdG9yIFJldmlzaW9uPTB4MjAxOTEwMTgKICovCi8qCiAgU1NEVDogTGVu Z3RoPTExMDk3LCBSZXZpc2lvbj0yLCBDaGVja3N1bT0xMzgsCglPRU1JRD1IUFFPRU0sIE9FTSBU YWJsZSBJRD04NzA5LCBPRU0gUmV2aXNpb249MHgzMDAwLAoJQ3JlYXRvciBJRD1BQ1BJLCBDcmVh dG9yIFJldmlzaW9uPTB4MjAxOTEwMTgKICovCi8qCiAgUFREVDogTGVuZ3RoPTMzMjYsIFJldmlz aW9uPTAsIENoZWNrc3VtPTEyNiwKCU9FTUlEPUhQUU9FTSwgT0VNIFRhYmxlIElEPTg3MDksIE9F TSBSZXZpc2lvbj0weDUsCglDcmVhdG9yIElEPUhQLCBDcmVhdG9yIFJldmlzaW9uPTB4MTAwMDAw ZAogKi8KLyoKICBXU01UOiBMZW5ndGg9NDAsIFJldmlzaW9uPTEsIENoZWNrc3VtPTcwLAoJT0VN SUQ9SFBRT0VNLCBPRU0gVGFibGUgSUQ9ODcwOSwgT0VNIFJldmlzaW9uPTB4MTA3MjAwOSwKCUNy ZWF0b3IgSUQ9SFAsIENyZWF0b3IgUmV2aXNpb249MHgxMDAxMwogKi8KLyoKICBGUERUOiBMZW5n dGg9NjgsIFJldmlzaW9uPTEsIENoZWNrc3VtPTE1LAoJT0VNSUQ9SFBRT0VNLCBPRU0gVGFibGUg SUQ9ODcwOSwgT0VNIFJldmlzaW9uPTB4MTA3MjAwOSwKCUNyZWF0b3IgSUQ9SFAsIENyZWF0b3Ig UmV2aXNpb249MHgxMDAwMDEzCiAqLwovKgogIEJHUlQ6IExlbmd0aD01NiwgUmV2aXNpb249MSwg Q2hlY2tzdW09MjA1LAoJT0VNSUQ9SFBRT0VNLCBPRU0gVGFibGUgSUQ9ODcwOSwgT0VNIFJldmlz aW9uPTB4MTA3MjAwOSwKCUNyZWF0b3IgSUQ9SFAsIENyZWF0b3IgUmV2aXNpb249MHgxMDAxMwog Ki8K --=_2d58dca25f95ab28b533ae54b1567b6b-- From owner-freebsd-current@freebsd.org Thu Dec 31 05:04:17 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 C9F924DC3C7 for ; Thu, 31 Dec 2020 05:04:17 +0000 (UTC) (envelope-from neel@neelc.org) Received: from rainpuddle.neelc.org (rainpuddle.neelc.org [66.42.69.219]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4D5x006Flbz3l5F for ; Thu, 31 Dec 2020 05:04:16 +0000 (UTC) (envelope-from neel@neelc.org) Received: from mail.neelc.org (rainpuddle.neelc.org [IPv6:2001:19f0:8001:fed:5400:2ff:fe73:c622]) by rainpuddle.neelc.org (Postfix) with ESMTPSA id 0DA3CEB2A5; Wed, 30 Dec 2020 21:04:13 -0800 (PST) MIME-Version: 1.0 Date: Wed, 30 Dec 2020 21:04:12 -0800 From: Neel Chauhan To: Chuck Tuffli Cc: FreeBSD-Current Subject: Re: Intel TigerLake NVMe vmd: Adding Support & Debugging a Patch In-Reply-To: References: User-Agent: Roundcube Webmail/1.4.9 Message-ID: <75d6b956e227249774978dc09cd26c3f@neelc.org> X-Sender: neel@neelc.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4D5x006Flbz3l5F X-Spamd-Bar: - X-Spamd-Result: default: False [-1.80 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEFALL_USER(0.00)[neel]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[66.42.69.219:from]; R_SPF_ALLOW(-0.20)[+a]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; SPAMHAUS_ZRD(0.00)[66.42.69.219:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[neelc.org,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:20473, ipnet:66.42.64.0/20, 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.34 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, 31 Dec 2020 05:04:17 -0000 I think I found the issue: This PCIe controller is not detected: 10000:e0:1d.0 PCI bridge [0604]: Intel Corporation Tiger Lake-LP PCI Express Root Port #9 [8086:a0b0] (rev 20) SI I believe the above PCIe controller is exposed by VMD (as it is on Linux), but FreeBSD vmd/vmd_bus is unable to attach this controller. It is likely because VMD uses PCI domain above 0x10000 but we aren't looking at this. Source: https://github.com/torvalds/linux/blob/master/drivers/pci/controller/vmd.c#L437 Don't yet have a patch though. Sorry for the number of emails earlier. -Neel On 2020-12-30 10:04, Chuck Tuffli wrote: > On Tue, Dec 29, 2020 at 6:30 PM Neel Chauhan wrote: >> >> Hi freebsd-hackers@, CC'd freebsd-current@, >> >> I hope you all had a wonderful holiday season. >> >> I recently got a HP Spectre x360 13t-aw200 which is an Intel >> TigerLake-based laptop. It has the Intel "Evo" branding and an >> "Optane" >> SSD which I disabled (so I can get a "second" SSD). >> >> On the Spectre, the NVMe is not detected: https://imgur.com/a/ighTwHQ >> >> I don't know if it is HP or Intel, but the VMD IDs device id is >> 8086:9a0b. I'm guessing Intel since Dell laptops (XPS, Vostro) also >> have >> this device ID [1]. >> >> Sadly, NVMe RAID is forced on this laptop. >> >> I wrote a rough patch to add the device IDs, and the patch is below: > > FWIW, that is the same change I would have made. Peeking at the Linux > vmd driver, it doesn't appear to do anything special for 8086:9a0b as > compared to the 8086:2a0c device the FreeBSD driver already supports. > That said, the Linux driver reads a capability register to determine > the bus number start (vmd_bus_number_start()) which I don't see in the > FreeBSD driver. This is curious because, looking at the "lspci all" > output from the XPS link you provided, the NVMe device shows up in PCI > domain 0x1000 (i.e. not 0x0000). Which (and I have no direct > experience with this device or code) only happens if the bus number > start function returns 0x0. > > What is the output from > # pciconf -rb pci0:0:14:0 0x40:0x48 > > --chuck > _______________________________________________ > 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 Dec 31 05:07:35 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 620B34DC4E3 for ; Thu, 31 Dec 2020 05:07:35 +0000 (UTC) (envelope-from darkfiberiru@gmail.com) Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D5x3p2PcGz3lSQ; Thu, 31 Dec 2020 05:07:33 +0000 (UTC) (envelope-from darkfiberiru@gmail.com) Received: by mail-lf1-x132.google.com with SMTP id y19so41852025lfa.13; Wed, 30 Dec 2020 21:07:33 -0800 (PST) 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=Auhow6DajzkyiONgttygB6LiH1ljN45WvbMHkBoGq2M=; b=Y3ryv5700pbF600L39IuD9DzI7immtj140d9sAnqPLX2GOkD8vTGIUVieBeSEs9bnK lnE0E0ACrcHAx/t8a004ORc44nDIRvGkld2L06jZrlmo3VlRIJSrEVairo2rYa65bGVI l5QKE+GittRf+eWX/x/rsgL7l4I2uLMWoMDyaiumcpZbk8VPOvzJA9lHbW/FfRtZVWUC /OyBGms9Jfwq5ybEQWhFBNmXNqPPZC+glf6Tg8WCGRKu67HtBy0opaMUxws78gJhN4E4 5xqRMuWmN5R+V5q4ybye7GpFjUbRJ2PeKj6zSUnmuOmbLNv7ITCiqrGo3WFIrwqsa9zJ vIPw== X-Gm-Message-State: AOAM5338EzMrLIEjaORmyC8Lyj0sqiB3fX31KpmvGxUK8bubMeE4xI63 VSRzZUW8RSA2NGtoiQLj1HgTkXrHtiSDQ9jkLcQFQNayTyY= X-Google-Smtp-Source: ABdhPJw1G3WAk4d1M9oN/RbN5vjxrMiNzUR0l6RUghifzyk2s6MkVfChyqEqnZcJ147EFv/FuCVmjuICK85uK/a1fw8= X-Received: by 2002:ac2:5dd1:: with SMTP id x17mr22319593lfq.252.1609391251092; Wed, 30 Dec 2020 21:07:31 -0800 (PST) MIME-Version: 1.0 References: <746a3af4-3daf-9029-bf48-23efa3f5da8e@gmail.com> <37d2a873-8cb9-b858-fa06-4bbfcf006835@gmail.com> <1e9e8649-0fe7-4b83-078d-f67908e2f430@gmail.com> <40C5DB30-4B7C-4A51-8069-B4E67298C558@FreeBSD.org> <9b6bbf0b-93d2-123e-ee5c-f8de660b150a@gmail.com> In-Reply-To: From: Nick Wolff Date: Thu, 31 Dec 2020 00:07:17 -0500 Message-ID: Subject: Re: usr.bin/xinstall r366697 versus: buildworld: lib/libc: install: short write to libc.so.7.debug: [_libinstall] Error code 71 To: Ryan Moeller Cc: Graham Perrin , Kyle Evans , Alex Richardson , Matthew Macy , Dimitry Andric , FreeBSD-CURRENT X-Rspamd-Queue-Id: 4D5x3p2PcGz3lSQ X-Spamd-Bar: + X-Spamd-Result: default: False [1.10 / 15.00]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; URI_COUNT_ODD(1.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MIME_BASE64_TEXT(0.10)[]; RCPT_COUNT_SEVEN(0.00)[7]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a00:1450:4864:20::132:from]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(1.00)[1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; SPAMHAUS_ZRD(0.00)[2a00:1450:4864:20::132:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::132:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 31 Dec 2020 05:07:35 -0000 I also have this breaking builds. Do we have plans to revert this until a variant that doesn't break builds in some corner cases is completed? On Tue, Dec 15, 2020 at 12:22 PM Ryan Moeller wrote: > > On 12/12/20 2:15 AM, Graham Perrin wrote: > > On 23/11/2020 12:18, Graham Perrin wrote: > > > >> On 22/11/2020 12:00, Dimitry Andric wrote: > >>> =E2=80=A6 > >>> I'd guess it's an unintended side-effect of > >>> https://svnweb.freebsd.org/base?view=3Drevision&revision=3D366697 > >>> ("install(1): Avoid unncessary fstatfs() calls and use mmap() based o= n > >>> size"). > >>> > >>> If you only revert usr.bin/xinstall to r366696, and then rebuild it, > >>> does it still occur? > >>> > >>> -Dimitry > >> > >> Thank you! > >> > >> Success with r366696: > >> > >> ---- > >> > >> =E2=80=A6 > > > > > > Re: > > < > https://lists.freebsd.org/pipermail/freebsd-current/2020-November/077634.= html> > > > please, should I open a bug for this? > > > > > > Is the issue exposed by my choice of gzip-9 for e.g. /usr/ and if so, > > can I avoid it by (now) reverting to lz4 for that part, and/or any > > other part, of the file system? > > > > > > Unfortunately I don't have an answer for you at this time, but ACK. > > > -Ryan > > > > ---- > > > > > > root@mowa219-gjp4-8570p:~ # zfs get mountpoint,compression > > NAME PROPERTY VALUE SOURCE > > Transcend mountpoint /Volumes/t500 loc= al > > Transcend compression zstd > > local > > Transcend/VirtualBox mountpoint /Volumes/t500/VirtualBox inherited > > from Transcend > > Transcend/VirtualBox compression zstd inherited from Transcend > > copperbowl mountpoint /copperbowl > > local > > copperbowl compression lz4 > > local > > copperbowl/ROOT mountpoint > > none local > > copperbowl/ROOT compression lz4 inherited from copperbowl > > copperbowl/ROOT/Waterfox mountpoint > > / local > > copperbowl/ROOT/Waterfox compression lz4 inherited from copperbowl > > copperbowl/ROOT/r367081f mountpoint > > / local > > copperbowl/ROOT/r367081f compression lz4 inherited from copperbowl > > copperbowl/ROOT/r367936e mountpoint > > / local > > copperbowl/ROOT/r367936e compression lz4 inherited from copperbowl > > copperbowl/ROOT/r367936f mountpoint > > / local > > copperbowl/ROOT/r367936f compression lz4 inherited from copperbowl > > copperbowl/ROOT/r367936f@2020-03-20-06:19:45 mountpoint > > - - > > copperbowl/ROOT/r367936f@2020-03-20-06:19:45 compression > > - - > > copperbowl/ROOT/r367936f@2020-11-22-23:18:47 mountpoint > > - - > > copperbowl/ROOT/r367936f@2020-11-22-23:18:47 compression > > - - > > copperbowl/ROOT/r367936f@2020-12-06-16:23:14 mountpoint > > - - > > copperbowl/ROOT/r367936f@2020-12-06-16:23:14 compression > > - - > > copperbowl/VirtualBox mountpoint > > /usr/local/VirtualBox local > > copperbowl/VirtualBox compression > > gzip-9 local > > copperbowl/iocage mountpoint /copperbowl/iocage inherited from > > copperbowl > > copperbowl/iocage compression > > gzip-9 local > > copperbowl/iocage/download mountpoint /copperbowl/iocage/download > > inherited from copperbowl > > copperbowl/iocage/download compression > > lz4 local > > copperbowl/iocage/download/12.0-RELEASE mountpoint > > /copperbowl/iocage/download/12.0-RELEASE inherited from copperbowl > > copperbowl/iocage/download/12.0-RELEASE compression > > lz4 local > > copperbowl/iocage/images mountpoint /copperbowl/iocage/images > > inherited from copperbowl > > copperbowl/iocage/images compression > > lz4 local > > copperbowl/iocage/jails mountpoint /copperbowl/iocage/jails > > inherited from copperbowl > > copperbowl/iocage/jails compression > > lz4 local > > copperbowl/iocage/jails/jbrowsers mountpoint > > /copperbowl/iocage/jails/jbrowsers inherited from copperbowl > > copperbowl/iocage/jails/jbrowsers compression lz4 inherited from > > copperbowl/iocage/jails > > copperbowl/iocage/jails/jbrowsers/root mountpoint > > /copperbowl/iocage/jails/jbrowsers/root inherited from copperbowl > > copperbowl/iocage/jails/jbrowsers/root compression lz4 inherited from > > copperbowl/iocage/jails > > copperbowl/iocage/log mountpoint /copperbowl/iocage/log inherited > > from copperbowl > > copperbowl/iocage/log compression > > lz4 local > > copperbowl/iocage/releases mountpoint /copperbowl/iocage/releases > > inherited from copperbowl > > copperbowl/iocage/releases compression > > lz4 local > > copperbowl/iocage/releases/12.0-RELEASE mountpoint > > /copperbowl/iocage/releases/12.0-RELEASE inherited from copperbowl > > copperbowl/iocage/releases/12.0-RELEASE compression lz4 inherited > > from copperbowl/iocage/releases > > copperbowl/iocage/releases/12.0-RELEASE/root mountpoint > > /copperbowl/iocage/releases/12.0-RELEASE/root inherited from copperbowl > > copperbowl/iocage/releases/12.0-RELEASE/root compression > > lz4 local > > copperbowl/iocage/releases/12.0-RELEASE/root@jbrowsers mountpoint > > - - > > copperbowl/iocage/releases/12.0-RELEASE/root@jbrowsers compression > > - - > > copperbowl/iocage/templates mountpoint /copperbowl/iocage/templates > > inherited from copperbowl > > copperbowl/iocage/templates compression > > lz4 local > > copperbowl/poudriere mountpoint /copperbowl/poudriere inherited from > > copperbowl > > copperbowl/poudriere compression > > gzip-9 local > > copperbowl/poudriere/data mountpoint > > /usr/local/poudriere/data local > > copperbowl/poudriere/data compression > > gzip-9 local > > copperbowl/poudriere/data/.m mountpoint /usr/local/poudriere/data/.m > > inherited from copperbowl/poudriere/data > > copperbowl/poudriere/data/.m compression gzip-9 inherited from > > copperbowl/poudriere/data > > copperbowl/poudriere/data/cache mountpoint > > /usr/local/poudriere/data/cache inherited from copperbowl/poudriere/dat= a > > copperbowl/poudriere/data/cache compression > > off local > > copperbowl/poudriere/data/logs mountpoint > > /usr/local/poudriere/data/logs inherited from copperbowl/poudriere/data > > copperbowl/poudriere/data/logs compression > > gzip-9 local > > copperbowl/poudriere/data/packages mountpoint > > /usr/local/poudriere/data/packages inherited from > > copperbowl/poudriere/data > > copperbowl/poudriere/data/packages compression > > off local > > copperbowl/poudriere/data/wrkdirs mountpoint > > /usr/local/poudriere/data/wrkdirs inherited from > > copperbowl/poudriere/data > > copperbowl/poudriere/data/wrkdirs compression > > off local > > copperbowl/poudriere/jails mountpoint /copperbowl/poudriere/jails > > inherited from copperbowl > > copperbowl/poudriere/jails compression > > gzip-9 local > > copperbowl/poudriere/jails/head mountpoint > > /usr/local/poudriere/jails/head local > > copperbowl/poudriere/jails/head compression > > gzip-9 local > > copperbowl/poudriere/jails/head@clean mountpoint > > - - > > copperbowl/poudriere/jails/head@clean compression > > - - > > copperbowl/poudriere/ports mountpoint /copperbowl/poudriere/ports > > inherited from copperbowl > > copperbowl/poudriere/ports compression gzip-9 inherited from > > copperbowl/poudriere > > copperbowl/poudriere/ports/default mountpoint > > /usr/local/poudriere/ports/default local > > copperbowl/poudriere/ports/default compression > > gzip-9 local > > copperbowl/poudriere/ports/freebsd-ports-kde mountpoint > > /usr/local/poudriere/ports/freebsd-ports-kde local > > copperbowl/poudriere/ports/freebsd-ports-kde compression > > gzip-9 local > > copperbowl/tmp mountpoint > > /tmp local > > copperbowl/tmp compression > > off local > > copperbowl/usr mountpoint > > /usr local > > copperbowl/usr compression > > gzip-9 local > > copperbowl/usr/home mountpoint /usr/home inherited from copperbowl/us= r > > copperbowl/usr/home compression > > lz4 local > > copperbowl/usr/home@2020-09-19-20:29-r365364 mountpoint > > - - > > copperbowl/usr/home@2020-09-19-20:29-r365364 compression > > - - > > copperbowl/usr/ports mountpoint /usr/ports inherited from > > copperbowl/usr > > copperbowl/usr/ports compression gzip-9 inherited from copperbowl/usr > > copperbowl/usr/src mountpoint /usr/src inherited from copperbowl/usr > > copperbowl/usr/src compression gzip-9 inherited from copperbowl/usr > > copperbowl/var mountpoint > > /var local > > copperbowl/var compression lz4 inherited from copperbowl > > copperbowl/var/audit mountpoint /var/audit inherited from > > copperbowl/var > > copperbowl/var/audit compression lz4 inherited from copperbowl > > copperbowl/var/crash mountpoint /var/crash inherited from > > copperbowl/var > > copperbowl/var/crash compression lz4 inherited from copperbowl > > copperbowl/var/log mountpoint /var/log inherited from copperbowl/var > > copperbowl/var/log compression lz4 inherited from copperbowl > > copperbowl/var/mail mountpoint /var/mail inherited from copperbowl/va= r > > copperbowl/var/mail compression lz4 inherited from copperbowl > > copperbowl/var/tmp mountpoint /var/tmp inherited from copperbowl/var > > copperbowl/var/tmp compression lz4 inherited from copperbowl > > copperbowl/vm-bhyve mountpoint /copperbowl/vm-bhyve inherited from > > copperbowl > > copperbowl/vm-bhyve compression gzip-9 > > > > _______________________________________________ > > 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" > _______________________________________________ > 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 Dec 31 05:13: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 3547F4DC863 for ; Thu, 31 Dec 2020 05:13:20 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4D5xBR75Jfz3m0f for ; Thu, 31 Dec 2020 05:13:19 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: by mailman.nyi.freebsd.org (Postfix) id F36334DCA41; Thu, 31 Dec 2020 05:13:19 +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 F323B4DC862 for ; Thu, 31 Dec 2020 05:13:19 +0000 (UTC) (envelope-from roberthuff@rcn.com) Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) (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 4D5xBQ6PNSz3ljQ for ; Thu, 31 Dec 2020 05:13:18 +0000 (UTC) (envelope-from roberthuff@rcn.com) X_CMAE_Category: , , X-CNFS-Analysis: v=2.3 cv=A5ASwJeG c=1 sm=1 tr=0 cx=a_idp_x a=9TgA2UwI6Wy+6BV4wQM/cQ==:117 a=9TgA2UwI6Wy+6BV4wQM/cQ==:17 a=KGjhK52YXX0A:10 a=kj9zAlcOel0A:10 a=XRQyMpdBKAEA:10 a=zTNgK-yGK50A:10 a=48faUk6PgeAA:10 a=6I5d2MoRAAAA:8 a=8cke9RrQ6PZVk32h8pQA:9 a=CjuIK1q_8ugA:10 a=FL76T4nP6cMA:10 a=EldiDC-a73cA:10 a=IjZwj45LgO3ly-622nXo:22 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine X-Authed-Username: cm9iZXJ0aHVmZkByY24uY29t Received: from [209.6.230.48] ([209.6.230.48:63321] helo=jerusalem.litteratus.org.litteratus.org) by smtp.rcn.com (envelope-from ) (ecelerity 3.6.25.56547 r(Core:3.6.25.0)) with ESMTPSA (cipher=AES256-GCM-SHA384) id F2/4A-54275-DED5DEF5; Thu, 31 Dec 2020 00:13:17 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24557.24044.631975.277382@jerusalem.litteratus.org> Date: Thu, 31 Dec 2020 00:13:16 -0500 From: Robert Huff To: current@freebsd.org CC: Robert Huff Subject: problem building kernel for r368820 X-Mailer: VM 8.2.0b under 27.1 (amd64-portbld-freebsd13.0) X-Vade-Verditct: clean X-Vade-Analysis: gggruggvucftvghtrhhoucdtuddrgedujedrvddvgedgkeegucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuufgjpfetvefqtffnvggrrhhnihhnghdptfevpfdpqfgfvfenuceurghilhhouhhtmecufedtudenucenucfjughrpeggtgfgkfffhffvuffosehtjeertdertddvnecuhfhrohhmpeftohgsvghrthcujfhufhhfuceorhhosggvrhhthhhufhhfsehrtghnrdgtohhmqeenucggtffrrghtthgvrhhnpeehfeefgefhieegvdeuteeljeekleeuuedulefgudegleevfeetvddvgfetvdffveenucffohhmrghinhepfhhrvggvsghsugdrohhrghenucfkphepvddtledriedrvdeftddrgeeknecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepvddtledriedrvdeftddrgeeknedpmhgrihhlfhhrohhmpehrohgsvghrthhhuhhffhesrhgtnhdrtghomhenpdhrtghpthhtoheptghurhhrvghnthesfhhrvggvsghsugdrohhrghen X-Rspamd-Queue-Id: 4D5xBQ6PNSz3ljQ X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.10 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[rcn.com:s=20180516]; RWL_MAILSPIKE_POSSIBLE(0.00)[69.168.97.78:from]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:69.168.97.0/24]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; SPAMHAUS_ZRD(0.00)[69.168.97.78:from:127.0.2.255]; DWL_DNSWL_LOW(-1.00)[rcn.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[rcn.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[rcn.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[69.168.97.78:from]; ASN(0.00)[asn:36271, ipnet:69.168.97.0/24, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[current]; RCVD_IN_DNSWL_LOW(-0.10)[69.168.97.78:from] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 31 Dec 2020 05:13:20 -0000 Hello: I'm trying to update a system from: FreeBSD 13.0-CURRENT #0 r365372: Sun Sep 6 10:51:26 EDT 2020 amd64 to the latest version. buildworld completes successfully. buildkernel, however, dies with: struct device dev; ^ /usr/src/sys/sys/types.h:275:16: note: forward declaration of 'struct device' typedef struct device *device_t; ^ 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: /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/backlight.h:152:9: error: implicit declaration of function 'dev_get_drvdata' is invalid 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/gplv2/src/linux_backlight.c:12: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/device.h:4: /usr/src/sys/compat/linuxkpi/common/include/linux/device.h:212:1: error: static 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:242: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/gplv2/src/linux_backlight.c:12: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/device.h:4: /usr/src/sys/compat/linuxkpi/common/include/linux/device.h:219:1: error: static 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:248: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/gplv2/src/linux_backlight.c:12: In file included from /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/include/linux/device.h:4: /usr/src/sys/compat/linuxkpi/common/include/linux/device.h:438:1: error: static 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:236:2: note: previous implicit declaration is here device_unregister(&client->dev); ^ /usr/local/sys/modules/drm-current-kmod/linuxkpi/gplv2/src/linux_backlight.c:277:27: error: initializing 'struct backlight_device *' with an expression of incompatible type 'void' struct backlight_device *bd = to_backlight_device(dev); ^ ~~~~~~~~~~~~~~~~~~~~~~~~ 12 errors generated. *** Error code 1 Stop. make[4]: stopped in /usr/local/sys/modules/drm-current-kmod/linuxkpi *** Error code 1 *** Error code 1 (The configuration file is appended.) There's nothing in UPDATING to suggest a cause, and I haven't seen anything on this list. This implies it's my fault. Help, please? Respectfully, Robert Huff # # JERUSALEM -- kernel configuration file for FreeBSD/amd64 # # For more information on this file, please read the config(5) manual page, # and/or the handbook section on Kernel Configuration Files: # # https://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (https://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: head/sys/amd64/conf/GENERIC 343949 2019-02-10 07:54:46Z cem $ cpu HAMMER ident JERUSALEM makeoptions DEBUG=-g # Build kernel with gdb(1) debug symbols makeoptions WITH_CTF=1 # Run ctfconvert(1) for DTrace support options SCHED_ULE # ULE scheduler options NUMA # Non-Uniform Memory Architecture support options PREEMPTION # Enable kernel thread preemption options VIMAGE # Subsystem virtualization, e.g. VNET options INET # InterNETworking options INET6 # IPv6 communications protocols options IPSEC_SUPPORT # Allow kldload of ipsec and tcpmd5 options ROUTE_MPATH # Multipath routing support options TCP_OFFLOAD # TCP offload options TCP_BLACKBOX # Enhanced TCP event logging options TCP_HHOOK # hhook(9) framework for TCP options TCP_RFC7413 # TCP Fast Open options SCTP_SUPPORT # Allow kldload of SCTP options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options UFS_GJOURNAL # Enable gjournal-based UFS journaling options QUOTA # Enable disk quotas for UFS options MD_ROOT # MD is a potential root device options NFSCL # Network Filesystem Client options NFSD # Network Filesystem Server options NFSLOCKD # Network Lock Manager options NFS_ROOT # NFS usable as /, requires NFSCL options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options TMPFS # Efficient memory filesystem options GEOM_PART_GPT # GUID Partition Tables. options GEOM_RAID # Soft RAID functionality. options GEOM_LABEL # Provides labelization options EFIRT # EFI Runtime Services support options COMPAT_FREEBSD32 # Compatible with i386 binaries options COMPAT_FREEBSD11 # Compatible with FreeBSD11 options COMPAT_FREEBSD12 # Compatible with FreeBSD12 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI options KTRACE # ktrace(1) support options STACK # stack(9) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options PRINTF_BUFR_SIZE=128 # Prevent printf output being interspersed. options KBD_INSTALL_CDEV # install a CDEV entry in /dev options HWPMC_HOOKS # Necessary kernel hooks for hwpmc(4) options AUDIT # Security event auditing options CAPABILITY_MODE # Capsicum capability mode options CAPABILITIES # Capsicum capabilities options MAC # TrustedBSD MAC Framework options KDTRACE_FRAME # Ensure frames are compiled in options KDTRACE_HOOKS # Kernel DTrace hooks options DDB_CTF # Kernel ELF linker loads CTF data options INCLUDE_CONFIG_FILE # Include this file in kernel options RACCT # Resource accounting framework options RACCT_DEFAULT_TO_DISABLED # Set kern.racct.enable=0 by default options RCTL # Resource limits # Debugging support. Always need this: options KDB # Enable kernel debugger support. options KDB_TRACE # Print a stack trace for a panic. # For full debugger support use (turn off in stable branch): options BUF_TRACKING # Track buffer history options DDB # Support DDB. options FULL_BUF_TRACKING # Track more buffer history options GDB # Support remote GDB. options DEADLKRES # Enable the deadlock resolver options INVARIANTS # Enable calls of extra sanity checking options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS options QUEUE_MACRO_DEBUG_TRASH # Trash queue(2) internal pointers on invalidation options WITNESS # Enable checks to detect deadlocks and cycles options WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed options MALLOC_DEBUG_MAXZONES=8 # Separate malloc(9) zones options VERBOSE_SYSINIT=0 # Support debug.verbose_sysinit, off by default # Kernel dump features. options EKCD # Support for encrypted kernel dumps options GZIO # gzip-compressed kernel and user dumps options ZSTDIO # zstd-compressed kernel and user dumps options DEBUGNET # debugnet networking options NETDUMP # netdump(4) client support options NETGDB # netgdb(4) client support # Make an SMP-capable kernel by default options SMP # Symmetric MultiProcessor Kernel options EARLY_AP_STARTUP # CPU frequency control device cpufreq # Bus support. device acpi options IOMMU device pci options PCI_HP # PCI-Express native HotPlug options PCI_IOV # PCI SR-IOV support # Floppy drives device fdc # ATA controllers device ahci # AHCI-compatible SATA controllers device ata # Legacy ATA/SATA controllers device mvs # Marvell 88SX50XX/88SX60XX/88SX70XX/SoC SATA device siis # SiliconImage SiI3124/SiI3132/SiI3531 SATA # ATA/SCSI peripherals device scbus # SCSI bus (required for ATA/SCSI) device ch # SCSI media changers device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass # Passthrough device (direct ATA/SCSI access) device ses # Enclosure Services (SES and SAF-TE) #device ctl # CAM Target Layer # NVM Express (NVMe) support device nvme # base NVMe driver device nvd # expose NVMe namespaces as disks, depends on nvme # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device psm # PS/2 mouse device kbdmux # keyboard multiplexer device vga # VGA video card driver options VESA # Add support for VESA BIOS Extensions (VBE) device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc options SC_PIXEL_MODE # add support for the raster text mode # vt is the new video console driver device vt device vt_vga device vt_efifb device agp # support several AGP chipsets # PCCARD (PCMCIA) support # PCMCIA and cardbus bridge support device cbb # cardbus (yenta) bridge device pccard # PC Card (16-bit) bus device cardbus # CardBus (32-bit) bus # Serial (COM) ports device uart # Generic UART driver # Parallel port device ppc device ppbus # Parallel port bus (required) device lpt # Printer device ppi # Parallel port interface device #device vpo # Requires scbus and da device puc # Multi I/O cards and multi-channel UARTs # These PCI/PCI-X/PCIe Ethernet NICs use iflib infrastructure device iflib device em # Intel PRO/1000 Gigabit Ethernet Family device ix # Intel PRO/10GbE PCIE PF Ethernet device ixv # Intel PRO/10GbE PCIE VF Ethernet device ixl # Intel 700 Series Physical Function device iavf # Intel Adaptive Virtual Function device ice # Intel 800 Series Physical Function device vmx # VMware VMXNET3 Ethernet device axp # AMD EPYC integrated NIC # PCI Ethernet NICs. device bxe # Broadcom NetXtreme II BCM5771X/BCM578XX 10GbE device le # AMD Am7900 LANCE and Am79C9xx PCnet device ti # Alteon Networks Tigon I/II gigabit Ethernet # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support device ae # Attansic/Atheros L2 FastEthernet device age # Attansic/Atheros L1 Gigabit Ethernet device alc # Atheros AR8131/AR8132 Ethernet device ale # Atheros AR8121/AR8113/AR8114 Ethernet device bce # Broadcom BCM5706/BCM5708 Gigabit Ethernet device bfe # Broadcom BCM440x 10/100 Ethernet device bge # Broadcom BCM570xx Gigabit Ethernet device cas # Sun Cassini/Cassini+ and NS DP83065 Saturn device dc # DEC/Intel 21143 and various workalikes device et # Agere ET1310 10/100/Gigabit Ethernet device fxp # Intel EtherExpress PRO/100B (82557, 82558) device gem # Sun GEM/Sun ERI/Apple GMAC device jme # JMicron JMC250 Gigabit/JMC260 Fast Ethernet device lge # Level 1 LXT1001 gigabit Ethernet device msk # Marvell/SysKonnect Yukon II Gigabit Ethernet device nfe # nVidia nForce MCP on-board Ethernet device nge # NatSemi DP83820 gigabit Ethernet device re # RealTek 8139C+/8169/8169S/8110S device rl # RealTek 8129/8139 device sge # Silicon Integrated Systems SiS190/191 device sis # Silicon Integrated Systems SiS 900/SiS 7016 device sk # SysKonnect SK-984x & SK-982x gigabit Ethernet device ste # Sundance ST201 (D-Link DFE-550TX) device stge # Sundance/Tamarack TC9021 gigabit Ethernet device vge # VIA VT612x gigabit Ethernet device vr # VIA Rhine, Rhine II device xl # 3Com 3c90x (``Boomerang'', ``Cyclone'') # Wireless NIC cards device wlan # 802.11 support options IEEE80211_DEBUG # enable debug msgs options IEEE80211_SUPPORT_MESH # enable 802.11s draft support device wlan_wep # 802.11 WEP support device wlan_ccmp # 802.11 CCMP support device wlan_tkip # 802.11 TKIP support device wlan_amrr # AMRR transmit rate control algorithm device an # Aironet 4500/4800 802.11 wireless NICs. device ath # Atheros NICs device ath_pci # Atheros pci/cardbus glue device ath_hal # pci/cardbus chip support options AH_AR5416_INTERRUPT_MITIGATION # AR5416 interrupt mitigation options ATH_ENABLE_11N # Enable 802.11n support for AR5416 and later device ath_rate_sample # SampleRate tx rate control for ath #device bwi # Broadcom BCM430x/BCM431x wireless NICs. #device bwn # Broadcom BCM43xx wireless NICs. device ipw # Intel 2100 wireless NICs. device iwi # Intel 2200BG/2225BG/2915ABG wireless NICs. device iwn # Intel 4965/1000/5000/6000 wireless NICs. device malo # Marvell Libertas wireless NICs. device mwl # Marvell 88W8363 802.11n wireless NICs. device ral # Ralink Technology RT2500 wireless NICs. device wi # WaveLAN/Intersil/Symbol 802.11 wireless NICs. device wpi # Intel 3945ABG wireless NICs. # Pseudo devices. device crypto # core crypto support device loop # Network loopback device padlock_rng # VIA Padlock RNG device rdrand_rng # Intel Bull Mountain RNG device ether # Ethernet support device vlan # 802.1Q VLAN support device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device firmware # firmware assist module # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! # Note that 'bpf' is required for DHCP. device bpf # Berkeley packet filter # USB support options USB_DEBUG # enable debug msgs device uhci # UHCI PCI->USB interface device ohci # OHCI PCI->USB interface device ehci # EHCI PCI->USB interface (USB 2.0) device xhci # XHCI PCI->USB interface (USB 3.0) device usb # USB Bus (required) device ukbd # Keyboard device umass # Disks/Mass storage - Requires scbus and da # Sound support device sound # Generic sound driver (required) device snd_cmi # CMedia CMI8338/CMI8738 device snd_csa # Crystal Semiconductor CS461x/428x device snd_emu10kx # Creative SoundBlaster Live! and Audigy device snd_es137x # Ensoniq AudioPCI ES137x device snd_hda # Intel High Definition Audio device snd_ich # Intel, NVidia and other ICH AC'97 Audio device snd_via8233 # VIA VT8233x Audio # MMC/SD device mmc # MMC/SD bus device mmcsd # MMC/SD memory card device sdhci # Generic PCI SD Host Controller # VirtIO support device virtio # Generic VirtIO bus (required) device virtio_pci # VirtIO PCI device device vtnet # VirtIO Ethernet device device virtio_blk # VirtIO Block device device virtio_scsi # VirtIO SCSI device device virtio_balloon # VirtIO Memory Balloon device # HyperV drivers and enhancement support device hyperv # HyperV drivers # Xen HVM Guest Optimizations # NOTE: XENHVM depends on xenpci. They must be added or removed together. options XENHVM # Xen HVM kernel infrastructure device xenpci # Xen HVM Hypervisor services driver # Netmap provides direct access to TX/RX rings on supported NICs device netmap # netmap(4) support # evdev interface options EVDEV_SUPPORT # evdev support in legacy drivers device evdev # input event device support device uinput # install /dev/uinput cdev From owner-freebsd-current@freebsd.org Thu Dec 31 05:16:30 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 042254DCAB1 for ; Thu, 31 Dec 2020 05:16:30 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660046.outbound.protection.outlook.com [40.107.66.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D5xG55xKnz3m4N; Thu, 31 Dec 2020 05:16:29 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=PjGz8iZdCrNlfIw+JpfX+/Z2IHBi9Zps8Ci7wgMoERQvbDzwvsR+XG6q//Rk5n3Azh1JxO8NXqhMN1vZGgu8UCKX1o730XLM4q0En2FOq8SVCdrott03R6C4SCF6wKFRTvI737SOYhsl57oiKECWjRtE42A0c3y61VkfGgbtDKu4dOW4qKy/rDGoU8aR+5EucnRHvYcx8Ju6BmTbcaRpYN++N/jv6haFrh87Tl54yIvw0mGxDzyIjujNno7yAsRArNgINPQxuLq7m6JzQnrTB1S8imh8yYaG5dW5IYAY/xvtox5AFOzcYLz95Sr0I6tXKNIpF5dwZ4vH13nQunyBFg== 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=IMAvQKotJvvvZX0BXqL4guhVp1arJASSuHvkPJIvPFY=; b=bdCgxMKc19fWRB3kTr4bFYopVwdgbCrvK9KcL3clNUPD+gawnnSid3tWGaakaDL1YCFr8TTPPZeth11QOsr3SQsy536S+q4cXDUyuFp1Du3JKz4c4DO64YqxyAV48SePD7lw6d4WQppsGxOhM8uIjO5d8ILAw5KKQI0+/lcWQmLCalD5FajQAsPrsEDSwZXSTc6txGgNPPzPGTSPPsS4K7Or0mP6ApwF4AwBdeGRnBmFYYGMgluVKLRUBYCxKAev2YzKZ8o5wj4E3en/ifBvTWg/hSk/o5HnuBM71Kr8c7Gw54JVY7sVGFko5QVVUICAxNUJLotwx5cGxh7Wmn7JGA== 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 YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:19::29) by QB1PR01MB2867.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:3d::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3721.20; Thu, 31 Dec 2020 05:16:27 +0000 Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::3d86:c7f9:bc4c:40c0]) by YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::3d86:c7f9:bc4c:40c0%6]) with mapi id 15.20.3721.020; Thu, 31 Dec 2020 05:16:27 +0000 From: Rick Macklem To: Konstantin Belousov CC: "freebsd-current@freebsd.org" , Alan Somers , Kirk McKusick , Mark Johnston Subject: Re: r367672 broke the NFS server Thread-Topic: r367672 broke the NFS server Thread-Index: AQHW3k3ynlL3lGhXRkC37zjbBa1PUKoPmNaAgAA7NVaAABFYAIAAwg6J Date: Thu, 31 Dec 2020 05:16:27 +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: 9455ca48-988e-497d-b925-08d8ad4b39e8 x-ms-traffictypediagnostic: QB1PR01MB2867: 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: +iCteJfXi67+vexwT/hbfDJsrHqHfRDGe3y81MmPsvlrXLr+NFGj72nqONlZGfnFFILfG2rh7o6rfBHsToQDuLk1CGzG4QrwXX7CjfyvvN4FsJ42eEiMmSdsLUdGiSW9veLDIZN/Znk+A+vZjpVNafCHYMmz8QO1fqDJISNF3dJIV3rXj1dRa00F6NNiGq0ADY9jZT6WsIabShULhdgYw53AEOgq9pAI5FBivG/M2El4Xv/FfHXl7lOuyfF0oDENFOTXiY4FA9OnlPfDs79fjyCi9P1LIhzxyJD71SCW6lMjayOBjTZKxalJOtlmu6zw1jO50xRTt/udFawLFo7DcfHBX85yqSA9/x1L/qdpc5vzkSoSIXmk74ypIQlBjxd4zWoz7BsmMImyVF79wexbrK39A2eyhaEtGC0FOC5ZXzM+Uhews4baQfx+GM8IW5/h5XeV1GYScL49FoCYLAg2YQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(366004)(346002)(396003)(39860400002)(136003)(376002)(8936002)(26005)(2906002)(6506007)(8676002)(52536014)(76116006)(316002)(55016002)(91956017)(786003)(71200400001)(4326008)(186003)(54906003)(9686003)(66476007)(66446008)(66556008)(64756008)(966005)(86362001)(478600001)(7696005)(5660300002)(6916009)(33656002)(66946007)(83380400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?5TOXO8Uo30AZ9OggBjAofgys3aA2jK3MGAfDzciQ5pGZHoAZIj/PybSBJe?= =?iso-8859-1?Q?ENrVW78/r553atEUpmvuGkVA6w5gAbnn07r54Qz8nKFVsDsYYxKaxdw3su?= =?iso-8859-1?Q?SU98K2n6dFj9RHikHUrhJc23eH1K/KIVsC4/zvhGiYWQDOkaOj5fZufoV9?= =?iso-8859-1?Q?dWYhGg6XVGou226kZGtrxE27y7/C+ZfTFqvpKIqk5S2rkUkFhNY54oMp1/?= =?iso-8859-1?Q?lHX9wE8yc2/aPK8gGUL7lnySm9drfURc7aNkg+ITs/Ny7DoCL+rBHHVxqC?= =?iso-8859-1?Q?aFldLHuZSQxjjIDoyNGUALcRbNyO6nQPNX1MpgC7SQ3Y6zN/QMIPK334fu?= =?iso-8859-1?Q?yfRpk2POTiQo6SeI1DGwxkQVvoC1WwkEuIbZOJGu/KTC2wjLGq4eSclZSe?= =?iso-8859-1?Q?AMuFjff/uylew5DXyuDAeGz0EhvQfNGKlwmFnU8SGWFOluvYeVrOCwK1Vs?= =?iso-8859-1?Q?4OQAogifxy9NUL1b43LXoNmuP6HgVC+Go6hlVyBybY/OrU0siVVKypwGuy?= =?iso-8859-1?Q?z9dz6geVsqE4YX8cJnmKqYD0+pG00W+3QW2VBmjqm4KcKIravT1FpRNjOP?= =?iso-8859-1?Q?0LN8aMA1lHtncWWLZZq0Tz58SAb0e1lhjGmSXJHnsIJXR0sSlx/XoMxEXX?= =?iso-8859-1?Q?8l8pUYtmZg1ijtfraMFnBm4ZVeo8wAdZDBiXP3P64IRu5ASXxygZZbl7YZ?= =?iso-8859-1?Q?Kz63sAGVDckTTInDsZSxUdEsWaa8OyR1ofvvzFs0HSRCvPuZmg8f78KMg7?= =?iso-8859-1?Q?xzPgl+NAlustY/vIcKPqsU/ds0rKn/UK7xMtOG9ZL9UVPRD8+v5Xs3JAhl?= =?iso-8859-1?Q?wF62D6csipo2WOB2sbiNeBhGqh9k9WKu+6yYu96GOgUyYbzOQL1rDqdOx8?= =?iso-8859-1?Q?cQCfEDj3yOzgtB6NslT2iHdLNuYGk6aGbF9llHFtzwIVgGLLe7khyMaxSC?= =?iso-8859-1?Q?OCYqR8wPO7on/bJz6fG6PIYLEpK/wM+157wetE2cPufuH0oKY7Pq1H6wK0?= =?iso-8859-1?Q?L2/AbLCHiL+2WVF24=3D?= 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: YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 9455ca48-988e-497d-b925-08d8ad4b39e8 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Dec 2020 05:16:27.7881 (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: Mc5aQM2y4EsQD5zKd+U14YGb19dpdQmIS9meIg0zv9htWhKE7OnfyAUb+uX1sED+Od9RV3KuSLPNb/RnZYrFEQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: QB1PR01MB2867 X-Rspamd-Queue-Id: 4D5xG55xKnz3m4N X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 31 Dec 2020 05:16:30 -0000 Rick Macklem wrote:=0A= >Kostik wrote:=0A= > >=0A= > >Idea of the change is to restart the syscall at top level. So for NFS= =0A= > >server the right approach is to not send a response and also to not=0A= > >free the request mbuf chain, but to restart processing.=0A= > Yes. I took a look and I think restarting the operation by rolling the=0A= > working position in the mbuf lists back and redoing the operation=0A= > is feasible and easier than fixing the individual operations.=0A= >=0A= > For NFSv4, you cannot redo the entire compound, since non-idempotent=0A= > operations like exclusive open may have already been completed.=0A= > However, rolling back to the beginning of the operation should be=0A= > doable.=0A= Turned out to be quite easy. I'll stick a patch up on phabricator=0A= tomorrow, after I do a little more testing.=0A= NFSv4.0 is still broken, because it screws up the seqid, but I can=0A= fix that separately.=0A= =0A= I do see the code looping about 2-3 times before it gets a successful=0A= ufs_create(). Does that sound reasonable?=0A= Here's some debug printfs for the test run of 4 concurrent compiles.=0A= (proc=3D8 is create and proc=3D12 is remove. Each line is a ERELOOKUP=0A= retry. This is for the 4 threads, but I had the thread tid in another prin= tf=0A= and it showed 2-3 attempts for the same thread. They should be serialized= =0A= by the exclusive lock on the directory vnode.)=0A= tryag3 stat=3D0 proc=3D8=0A= tryag3 stat=3D0 proc=3D8=0A= tryag3 stat=3D0 proc=3D8=0A= tryag3 stat=3D0 proc=3D12=0A= tryag3 stat=3D0 proc=3D8=0A= tryag3 stat=3D0 proc=3D8=0A= tryag3 stat=3D0 proc=3D8=0A= tryag3 stat=3D0 proc=3D8=0A= tryag3 stat=3D0 proc=3D8=0A= tryag3 stat=3D0 proc=3D12=0A= tryag3 stat=3D0 proc=3D8=0A= tryag3 stat=3D0 proc=3D8=0A= tryag3 stat=3D0 proc=3D8=0A= tryag3 stat=3D0 proc=3D8=0A= tryag3 stat=3D0 proc=3D8=0A= tryag3 stat=3D0 proc=3D12=0A= tryag3 stat=3D0 proc=3D8=0A= tryag3 stat=3D0 proc=3D8=0A= tryag3 stat=3D0 proc=3D8=0A= tryag3 stat=3D0 proc=3D12=0A= tryag3 stat=3D0 proc=3D8=0A= tryag3 stat=3D0 proc=3D8=0A= tryag3 stat=3D0 proc=3D8=0A= tryag3 stat=3D0 proc=3D12=0A= tryag3 stat=3D0 proc=3D8=0A= tryag3 stat=3D0 proc=3D8=0A= tryag3 stat=3D0 proc=3D8=0A= tryag3 stat=3D0 proc=3D8=0A= tryag3 stat=3D0 proc=3D8=0A= tryag3 stat=3D0 proc=3D8=0A= tryag3 stat=3D0 proc=3D12=0A= tryag3 stat=3D0 proc=3D8=0A= tryag3 stat=3D0 proc=3D8=0A= =0A= Thanks for the suggestion, Kostik.=0A= =0A= rick=0A= =0A= > --> It will serve as a good test, in that it may expose bugs in the=0A= > RPC/operation code where failure (ERELOOKUP) doesn't clean=0A= > things up correctly.=0A= > --> In NFSv4, there is the open/lock state that cannot be updated= =0A= > for this error case. (The seqid stuff in NFSv4.0 Open can be = fun.=0A= > Its used to serialize the operations and the number must be= =0A= > incremented for some errors, but not for others. The 10026=0A= > error occurs when you don't get this right.)=0A= Note that ERELOOKUP error can only show up from the VOPs that modify the vo= lume.=0A= Otherwise we simply do not call into SU. In particular, I believe that ope= ns=0A= in the sense of NFS are safe.=0A= =0A= Regardless of it, there should be either a catch-all check for ERELOOKUP,= =0A= or assert that ERELOOKUP did not leaked, as it is done for syscalls=0A= =0A= >=0A= > I'll start working on this to-day, but I have no idea how long it might= =0A= > take?=0A= >=0A= > >I am sorry I forgot about NFS server when designing this fix, the only= =0A= > >mild excuse I can provide is that the change was quite complicated as is= .=0A= > >I will start looking at the fix.=0A= > No problem. Sometimes I'd like to forget about NFS too;-).=0A= >=0A= > For the rollback/redo the RPC/operation case, it's probably easier for me= =0A= > to do it. As above, I'll start on it, but...=0A= >=0A= > My main concern is how long it will take, given the FreeBSD13 release=0A= > starts soon.=0A= For sure I will help you if needed, and I believe that we could ask for=0A= testing from Peter.=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 Thu Dec 31 05:37:33 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 D38FE4DD601 for ; Thu, 31 Dec 2020 05:37:33 +0000 (UTC) (envelope-from neel@neelc.org) Received: from rainpuddle.neelc.org (rainpuddle.neelc.org [66.42.69.219]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4D5xkN6lFrz3mgL for ; Thu, 31 Dec 2020 05:37:32 +0000 (UTC) (envelope-from neel@neelc.org) Received: from mail.neelc.org (rainpuddle.neelc.org [IPv6:2001:19f0:8001:fed:5400:2ff:fe73:c622]) by rainpuddle.neelc.org (Postfix) with ESMTPSA id 45FE6EB2A5; Wed, 30 Dec 2020 21:37:30 -0800 (PST) MIME-Version: 1.0 Date: Wed, 30 Dec 2020 21:37:30 -0800 From: Neel Chauhan To: Chuck Tuffli Cc: FreeBSD-Current Subject: Re: Intel TigerLake NVMe vmd: Adding Support & Debugging a Patch In-Reply-To: <75d6b956e227249774978dc09cd26c3f@neelc.org> References: <75d6b956e227249774978dc09cd26c3f@neelc.org> User-Agent: Roundcube Webmail/1.4.9 Message-ID: <8978ff9014c0d6dddaf3fb0d599dfb59@neelc.org> X-Sender: neel@neelc.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4D5xkN6lFrz3mgL X-Spamd-Bar: - X-Spamd-Result: default: False [-1.80 / 15.00]; RCVD_TLS_ALL(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEFALL_USER(0.00)[neel]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[66.42.69.219:from]; R_SPF_ALLOW(-0.20)[+a]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; ARC_NA(0.00)[]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; SPAMHAUS_ZRD(0.00)[66.42.69.219:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[neelc.org,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:20473, ipnet:66.42.64.0/20, 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.34 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, 31 Dec 2020 05:37:33 -0000 On 2020-12-30 21:04, Neel Chauhan wrote: > It is likely because VMD uses PCI domain above 0x10000 but we aren't > looking at this. The 0x10000 is purely a Linux construct. It seems the PCI domains are virtual. Source: https://lists.x.org/archives/xorg-devel/2016-August/050590.html -Neel From owner-freebsd-current@freebsd.org Thu Dec 31 05:42:52 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 31FCD4DD3C4 for ; Thu, 31 Dec 2020 05:42:52 +0000 (UTC) (envelope-from neel@neelc.org) Received: from rainpuddle.neelc.org (rainpuddle.neelc.org [IPv6:2001:19f0:8001:fed:5400:2ff:fe73:c622]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4D5xrW3d4fz3njH for ; Thu, 31 Dec 2020 05:42:51 +0000 (UTC) (envelope-from neel@neelc.org) Received: from mail.neelc.org (rainpuddle.neelc.org [IPv6:2001:19f0:8001:fed:5400:2ff:fe73:c622]) by rainpuddle.neelc.org (Postfix) with ESMTPSA id 15645EB2A5 for ; Wed, 30 Dec 2020 21:42:42 -0800 (PST) MIME-Version: 1.0 Date: Wed, 30 Dec 2020 21:42:42 -0800 From: Neel Chauhan To: freebsd-current@freebsd.org Subject: PCIe Root Port/Bus Not Detected in VMD User-Agent: Roundcube Webmail/1.4.9 Message-ID: X-Sender: neel@neelc.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4D5xrW3d4fz3njH X-Spamd-Bar: - X-Spamd-Result: default: False [-1.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[neel]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2001:19f0:8001:fed:5400:2ff:fe73:c622:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[2001:19f0:8001:fed:5400:2ff:fe73:c622:from:127.0.2.255]; R_SPF_ALLOW(-0.20)[+a]; NEURAL_HAM_LONG(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[neelc.org,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_COUNT_ONE(0.00)[1]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:20473, ipnet:2001:19f0:8000::/38, country:US]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current]; ONCE_RECEIVED(0.10)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 31 Dec 2020 05:42:52 -0000 Hi freebsd-current@, My apologies for so many emails from me. I sent another copy of this email to freebsd-hackers@. I have the following patch: diff --git a/sys/dev/vmd/vmd.c b/sys/dev/vmd/vmd.c index 2cc6f45bed9..7cc0a8a91a7 100644 --- a/sys/dev/vmd/vmd.c +++ b/sys/dev/vmd/vmd.c @@ -66,10 +66,12 @@ struct vmd_type { #define INTEL_VENDOR_ID 0x8086 #define INTEL_DEVICE_ID_VMD 0x201d #define INTEL_DEVICE_ID_VMD2 0x28c0 +#define INTEL_DEVICE_ID_VMD3 0x9a0b static struct vmd_type vmd_devs[] = { { INTEL_VENDOR_ID, INTEL_DEVICE_ID_VMD, "Intel Volume Management Device" }, { INTEL_VENDOR_ID, INTEL_DEVICE_ID_VMD2, "Intel Volume Management Device" }, + { INTEL_VENDOR_ID, INTEL_DEVICE_ID_VMD3, "Intel Volume Management Device" }, { 0, 0, NULL } }; @@ -425,6 +427,7 @@ vmd_attach(device_t dev) return (0); fail: + rman_fini(&sc->vmd_bus.rman); vmd_free(sc); return (ENXIO); } This patch helps me detect the VMD controller, but I am unable to attach to it. Therefore, I am not able to attach any PCIe buses that will be used by a NVMe SSD. If this patch worked, I would see these devices (as I do in Linux): 10000:e0:1d.0 PCI bridge [0604]: Intel Corporation Tiger Lake-LP PCI Express Root Port #9 [8086:a0b0] (rev 20) SI 10000:e0:1d.2 PCI bridge [0604]: Intel Corporation Device [8086:a0b2] (rev 20) 10000:e1:00.0 Non-Volatile memory controller [0108]: Intel Corporation Device [8086:0975] (rev 03) 10000:e2:00.0 Non-Volatile memory controller [0108]: Intel Corporation Device [8086:0975] And therefore a `nvd*` device. Could a developer please help me with this? -Neel === https://www.neelc.org/ From owner-freebsd-current@freebsd.org Thu Dec 31 05:45: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 41F374DDA2D for ; Thu, 31 Dec 2020 05:45:25 +0000 (UTC) (envelope-from neel@neelc.org) Received: from rainpuddle.neelc.org (rainpuddle.neelc.org [66.42.69.219]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4D5xvS3dksz3nnH for ; Thu, 31 Dec 2020 05:45:24 +0000 (UTC) (envelope-from neel@neelc.org) Received: from mail.neelc.org (rainpuddle.neelc.org [IPv6:2001:19f0:8001:fed:5400:2ff:fe73:c622]) by rainpuddle.neelc.org (Postfix) with ESMTPSA id 3E7B1EB2A5 for ; Wed, 30 Dec 2020 21:45:22 -0800 (PST) MIME-Version: 1.0 Date: Wed, 30 Dec 2020 21:45:22 -0800 From: Neel Chauhan To: freebsd-current@freebsd.org Subject: Re: PCIe Root Port/Bus Not Detected in VMD In-Reply-To: References: User-Agent: Roundcube Webmail/1.4.9 Message-ID: X-Sender: neel@neelc.org Content-Type: multipart/mixed; boundary="=_7d45d6f8fa0f7ae54fef89b375820143" X-Rspamd-Queue-Id: 4D5xvS3dksz3nnH X-Spamd-Bar: / X-Spamd-Result: default: False [0.31 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+a:c]; HAS_ATTACHMENT(0.00)[]; TO_DN_NONE(0.00)[]; MIME_BASE64_TEXT_BOGUS(1.00)[]; NEURAL_HAM_SHORT(-0.99)[-0.986]; MIME_BASE64_TEXT(0.10)[]; CTYPE_MIXED_BOGUS(1.00)[]; DMARC_POLICY_ALLOW(-0.50)[neelc.org,none]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[66.42.69.219:from]; ASN(0.00)[asn:20473, ipnet:66.42.64.0/20, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:+]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[neel]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[66.42.69.219:from:127.0.2.255]; 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.34 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, 31 Dec 2020 05:45:25 -0000 --=_7d45d6f8fa0f7ae54fef89b375820143 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed For reference, I am attaching the `pciconf -lv` and `acpidump -dt` dumps. -Neel On 2020-12-30 21:42, Neel Chauhan wrote: > Hi freebsd-current@, > > My apologies for so many emails from me. I sent another copy of this > email to freebsd-hackers@. > > I have the following patch: > > diff --git a/sys/dev/vmd/vmd.c b/sys/dev/vmd/vmd.c > index 2cc6f45bed9..7cc0a8a91a7 100644 > --- a/sys/dev/vmd/vmd.c > +++ b/sys/dev/vmd/vmd.c > @@ -66,10 +66,12 @@ struct vmd_type { > #define INTEL_VENDOR_ID 0x8086 > #define INTEL_DEVICE_ID_VMD 0x201d > #define INTEL_DEVICE_ID_VMD2 0x28c0 > +#define INTEL_DEVICE_ID_VMD3 0x9a0b > > static struct vmd_type vmd_devs[] = { > { INTEL_VENDOR_ID, INTEL_DEVICE_ID_VMD, "Intel Volume > Management Device" }, > { INTEL_VENDOR_ID, INTEL_DEVICE_ID_VMD2, "Intel Volume > Management Device" }, > + { INTEL_VENDOR_ID, INTEL_DEVICE_ID_VMD3, "Intel Volume > Management Device" }, > { 0, 0, NULL } > }; > > @@ -425,6 +427,7 @@ vmd_attach(device_t dev) > return (0); > > fail: > + rman_fini(&sc->vmd_bus.rman); > vmd_free(sc); > return (ENXIO); > } > > This patch helps me detect the VMD controller, but I am unable to > attach to it. > > Therefore, I am not able to attach any PCIe buses that will be used by > a NVMe SSD. > > If this patch worked, I would see these devices (as I do in Linux): > > 10000:e0:1d.0 PCI bridge [0604]: Intel Corporation Tiger Lake-LP PCI > Express Root Port #9 [8086:a0b0] (rev 20) SI > 10000:e0:1d.2 PCI bridge [0604]: Intel Corporation Device [8086:a0b2] > (rev 20) > 10000:e1:00.0 Non-Volatile memory controller [0108]: Intel Corporation > Device [8086:0975] (rev 03) > 10000:e2:00.0 Non-Volatile memory controller [0108]: Intel Corporation > Device [8086:0975] > > And therefore a `nvd*` device. > > Could a developer please help me with this? > > -Neel > > === > > https://www.neelc.org/ > _______________________________________________ > 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" --=_7d45d6f8fa0f7ae54fef89b375820143 Content-Transfer-Encoding: base64 Content-Type: text/plain; name=acpidump.txt Content-Disposition: attachment; filename=acpidump.txt; size=10947 LyoKICBSU0QgUFRSOiBPRU09SFBRT0VNLCBBQ1BJX1Jldj0yLjB4ICgyKQoJWFNEVD0weDAwMDAw MDAwNTRkYmI3MjgsIGxlbmd0aD0zNiwgY2tzdW09MjA2CiAqLwovKgogIFhTRFQ6IExlbmd0aD0y NzYsIFJldmlzaW9uPTEsIENoZWNrc3VtPTU0LAoJT0VNSUQ9SFBRT0VNLCBPRU0gVGFibGUgSUQ9 U0xJQy1NUEMsIE9FTSBSZXZpc2lvbj0weDEwNzIwMDksCglDcmVhdG9yIElEPUFNSSwgQ3JlYXRv ciBSZXZpc2lvbj0weDEwMDAwMTMKCUVudHJpZXM9eyAweDAwMDAwMDAwNTRkYjYwMDAsIDB4MDAw MDAwMDA1NGRiYTAwMCwgMHgwMDAwMDAwMDU0ZGI3MDAwLCAweDAwMDAwMDAwNTRkNjEwMDAsIDB4 MDAwMDAwMDA1NGQ2MDAwMCwgMHgwMDAwMDAwMDU0ZDVjMDAwLCAweDAwMDAwMDAwNTRkNTUwMDAs IDB4MDAwMDAwMDA1NGQ0ODAwMCwgMHgwMDAwMDAwMDU0ZDQ3MDAwLCAweDAwMDAwMDAwNTRkNDUw MDAsIDB4MDAwMDAwMDA1NGQ0NDAwMCwgMHgwMDAwMDAwMDU0ZDQwMDAwLCAweDAwMDAwMDAwNTRk M2YwMDAsIDB4MDAwMDAwMDA1NGQzZTAwMCwgMHgwMDAwMDAwMDU0ZDNkMDAwLCAweDAwMDAwMDAw NTRkM2MwMDAsIDB4MDAwMDAwMDA1NGQzYjAwMCwgMHgwMDAwMDAwMDU0ZDNhMDAwLCAweDAwMDAw MDAwNTRkMzkwMDAsIDB4MDAwMDAwMDA1NGQzODAwMCwgMHgwMDAwMDAwMDU0ZDM3MDAwLCAweDAw MDAwMDAwNTRkZTYwMDAsIDB4MDAwMDAwMDA1NGRlNTAwMCwgMHgwMDAwMDAwMDU0ZDM2MDAwLCAw eDAwMDAwMDAwNTRkNDkwMDAsIDB4MDAwMDAwMDA1NGQ1OTAwMCwgMHgwMDAwMDAwMDU0ZDM1MDAw LCAweDAwMDAwMDAwNTRkNDMwMDAsIDB4MDAwMDAwMDA1NGQzNDAwMCwgMHgwMDAwMDAwMDU0ZDMz MDAwIH0KICovCi8qCiAgRkFDUDogTGVuZ3RoPTI3NiwgUmV2aXNpb249NiwgQ2hlY2tzdW09MTYz LAoJT0VNSUQ9SFBRT0VNLCBPRU0gVGFibGUgSUQ9U0xJQy1NUEMsIE9FTSBSZXZpc2lvbj0weDEw NzIwMDksCglDcmVhdG9yIElEPUhQLCBDcmVhdG9yIFJldmlzaW9uPTB4MTAwMTMKIAlGQUNTPTB4 NTRlNzcwMDAsIERTRFQ9MHg1NGQ2MjAwMAoJSU5UX01PREVMPVBJQwoJUHJlZmVycmVkX1BNX1By b2ZpbGU9TW9iaWxlICgyKQoJU0NJX0lOVD05CglTTUlfQ01EPTB4YjIsIEFDUElfRU5BQkxFPTB4 YTAsIEFDUElfRElTQUJMRT0weGExLCBTNEJJT1NfUkVRPTB4MAoJUFNUQVRFX0NOVD0weDAKCVBN MWFfRVZUX0JMSz0weDE4MDAtMHgxODAzCglQTTFhX0NOVF9CTEs9MHgxODA0LTB4MTgwNQoJUE0y X0NOVF9CTEs9MHgxODUwLTB4MTg1MAoJUE1fVE1SX0JMSz0weDE4MDgtMHgxODBiCglHUEUwX0JM Sz0weDE4NjAtMHgxODdmCglQX0xWTDJfTEFUPTEwMSB1cywgUF9MVkwzX0xBVD0xMDAxIHVzCglG TFVTSF9TSVpFPTEwMjQsIEZMVVNIX1NUUklERT0xNgoJRFVUWV9PRkZTRVQ9MSwgRFVUWV9XSURU SD0zCglEQVlfQUxSTT0xMywgTU9OX0FMUk09MCwgQ0VOVFVSWT01MAoJSUFQQ19CT09UX0FSQ0g9 ezgwNDIsTk9fQVNQTX0KCUZsYWdzPXtXQklOVkQsQzFfU1VQUE9SVEVELFNMRUVQX0JVVFRPTixT NF9SVENfV0FLRSxSRVNFVF9SRUdJU1RFUixQQ0lfRVhQUkVTU19XQUtFLFBMQVRGT1JNX0NMT0NL LFM0X1JUQ19WQUxJRCxSRU1PVEVfUE9XRVJfT04sTE9XX1BPV0VSX1MwfQoJUkVTRVRfUkVHPTB4 YjI6MFs4XSAoSU8pLCBSRVNFVF9WQUxVRT0weGViCiAqLwovKgogIEZBQ1M6CUxlbmd0aD02NCwg SHdTaWc9MHhjMGYxYmUyZiwgRmlybV9XYWtlX1ZlYz0weDAwMDAwMDAwCglHbG9iYWxfTG9jaz0K CUZsYWdzPQoJVmVyc2lvbj0yCiAqLwovKgogIERTRFQ6IExlbmd0aD0zNDE5MjQsIFJldmlzaW9u PTIsIENoZWNrc3VtPTE5NywKCU9FTUlEPUhQUU9FTSwgT0VNIFRhYmxlIElEPTg3MDksIE9FTSBS ZXZpc2lvbj0weDEwNzIwMDksCglDcmVhdG9yIElEPUFDUEksIENyZWF0b3IgUmV2aXNpb249MHgy MDE5MTAxOAogKi8KLyoKICBNQ0ZHOiBMZW5ndGg9NjAsIFJldmlzaW9uPTEsIENoZWNrc3VtPTM3 LAoJT0VNSUQ9SFBRT0VNLCBPRU0gVGFibGUgSUQ9ODcwOSwgT0VNIFJldmlzaW9uPTB4MTA3MjAw OSwKCUNyZWF0b3IgSUQ9SFAsIENyZWF0b3IgUmV2aXNpb249MHg5NwoKCUJhc2UgQWRkcmVzcz0w eDAwMDAwMDAwYzAwMDAwMDAKCVNlZ21lbnQgR3JvdXA9MHgwMDAwCglTdGFydCBCdXM9MAoJRW5k IEJ1cz0yNTUKICovCi8qCiAgU1NEVDogTGVuZ3RoPTk2NzksIFJldmlzaW9uPTIsIENoZWNrc3Vt PTczLAoJT0VNSUQ9SFBRT0VNLCBPRU0gVGFibGUgSUQ9ODcwOSwgT0VNIFJldmlzaW9uPTB4MzAw MCwKCUNyZWF0b3IgSUQ9QUNQSSwgQ3JlYXRvciBSZXZpc2lvbj0weDIwMTkxMDE4CiAqLwovKgog IEZJRFQ6IExlbmd0aD0xNTYsIFJldmlzaW9uPTEsIENoZWNrc3VtPTIxMCwKCU9FTUlEPUhQUU9F TSwgT0VNIFRhYmxlIElEPTg3MDksIE9FTSBSZXZpc2lvbj0weDEwNzIwMDksCglDcmVhdG9yIElE PUhQLCBDcmVhdG9yIFJldmlzaW9uPTB4MTAwMTMKICovCi8qCiAgTVNETTogTGVuZ3RoPTg1LCBS ZXZpc2lvbj0zLCBDaGVja3N1bT0xOTYsCglPRU1JRD1IUFFPRU0sIE9FTSBUYWJsZSBJRD1TTElD LU1QQywgT0VNIFJldmlzaW9uPTB4MSwKCUNyZWF0b3IgSUQ9SFAsIENyZWF0b3IgUmV2aXNpb249 MHgxMDAxMwogKi8KLyoKICBTU0RUOiBMZW5ndGg9MTMwNTYsIFJldmlzaW9uPTIsIENoZWNrc3Vt PTEwNywKCU9FTUlEPUhQUU9FTSwgT0VNIFRhYmxlIElEPTg3MDksIE9FTSBSZXZpc2lvbj0weDEw MDAsCglDcmVhdG9yIElEPUFDUEksIENyZWF0b3IgUmV2aXNpb249MHgyMDE5MTAxOAogKi8KLyoK ICBTU0RUOiBMZW5ndGg9MTMxMzYsIFJldmlzaW9uPTIsIENoZWNrc3VtPTQxLAoJT0VNSUQ9SFBR T0VNLCBPRU0gVGFibGUgSUQ9ODcwOSwgT0VNIFJldmlzaW9uPTB4MzAwMCwKCUNyZWF0b3IgSUQ9 QUNQSSwgQ3JlYXRvciBSZXZpc2lvbj0weDIwMTkxMDE4CiAqLwovKgogIEhQRVQ6IExlbmd0aD01 NiwgUmV2aXNpb249MSwgQ2hlY2tzdW09MzIsCglPRU1JRD1IUFFPRU0sIE9FTSBUYWJsZSBJRD04 NzA5LCBPRU0gUmV2aXNpb249MHgxMDcyMDA5LAoJQ3JlYXRvciBJRD1IUCwgQ3JlYXRvciBSZXZp c2lvbj0weDEwMDAwMTMKCUhQRVQgTnVtYmVyPTAKCUFERFI9MHgwMDAwMDAwMGZlZDAwMDAwOjBb NjRdIChNZW1vcnkpCglIVyBSZXY9MHgxCglDb21wYXJhdG9ycz0yCglDb3VudGVyIFNpemU9MQoJ TGVnYWN5IElSUSByb3V0aW5nIGNhcGFibGU9e1RSVUV9CglQQ0kgVmVuZG9yIElEPTB4ODA4NgoJ TWluaW1hbCBUaWNrPTEyOAoJRmxhZ3M9MHgwMAogKi8KLyoKICBBUElDOiBMZW5ndGg9MzAwLCBS ZXZpc2lvbj00LCBDaGVja3N1bT0yNDIsCglPRU1JRD1IUFFPRU0sIE9FTSBUYWJsZSBJRD04NzA5 LCBPRU0gUmV2aXNpb249MHgxMDcyMDA5LAoJQ3JlYXRvciBJRD1IUCwgQ3JlYXRvciBSZXZpc2lv bj0weDEwMDAwMTMKCUxvY2FsIEFQSUMgQUREUj0weGZlZTAwMDAwCglGbGFncz17UEMtQVR9CgoJ VHlwZT1Mb2NhbCBBUElDCglBQ1BJIENQVT0wCglGbGFncz17RU5BQkxFRH0KCUFQSUMgSUQ9MAoK CVR5cGU9TG9jYWwgQVBJQwoJQUNQSSBDUFU9MQoJRmxhZ3M9e0VOQUJMRUR9CglBUElDIElEPTIK CglUeXBlPUxvY2FsIEFQSUMKCUFDUEkgQ1BVPTIKCUZsYWdzPXtFTkFCTEVEfQoJQVBJQyBJRD00 CgoJVHlwZT1Mb2NhbCBBUElDCglBQ1BJIENQVT0zCglGbGFncz17RU5BQkxFRH0KCUFQSUMgSUQ9 NgoKCVR5cGU9TG9jYWwgQVBJQwoJQUNQSSBDUFU9NAoJRmxhZ3M9e0VOQUJMRUR9CglBUElDIElE PTEKCglUeXBlPUxvY2FsIEFQSUMKCUFDUEkgQ1BVPTUKCUZsYWdzPXtFTkFCTEVEfQoJQVBJQyBJ RD0zCgoJVHlwZT1Mb2NhbCBBUElDCglBQ1BJIENQVT02CglGbGFncz17RU5BQkxFRH0KCUFQSUMg SUQ9NQoKCVR5cGU9TG9jYWwgQVBJQwoJQUNQSSBDUFU9NwoJRmxhZ3M9e0VOQUJMRUR9CglBUElD IElEPTcKCglUeXBlPUxvY2FsIEFQSUMKCUFDUEkgQ1BVPTgKCUZsYWdzPXtESVNBQkxFRH0KCUFQ SUMgSUQ9MjU1CgoJVHlwZT1Mb2NhbCBBUElDCglBQ1BJIENQVT05CglGbGFncz17RElTQUJMRUR9 CglBUElDIElEPTI1NQoKCVR5cGU9TG9jYWwgQVBJQwoJQUNQSSBDUFU9MTAKCUZsYWdzPXtESVNB QkxFRH0KCUFQSUMgSUQ9MjU1CgoJVHlwZT1Mb2NhbCBBUElDCglBQ1BJIENQVT0xMQoJRmxhZ3M9 e0RJU0FCTEVEfQoJQVBJQyBJRD0yNTUKCglUeXBlPUxvY2FsIEFQSUMKCUFDUEkgQ1BVPTEyCglG bGFncz17RElTQUJMRUR9CglBUElDIElEPTI1NQoKCVR5cGU9TG9jYWwgQVBJQwoJQUNQSSBDUFU9 MTMKCUZsYWdzPXtESVNBQkxFRH0KCUFQSUMgSUQ9MjU1CgoJVHlwZT1Mb2NhbCBBUElDCglBQ1BJ IENQVT0xNAoJRmxhZ3M9e0RJU0FCTEVEfQoJQVBJQyBJRD0yNTUKCglUeXBlPUxvY2FsIEFQSUMK CUFDUEkgQ1BVPTE1CglGbGFncz17RElTQUJMRUR9CglBUElDIElEPTI1NQoKCVR5cGU9SU8gQVBJ QwoJQVBJQyBJRD0yCglJTlQgQkFTRT0wCglBRERSPTB4MDAwMDAwMDBmZWMwMDAwMAoKCVR5cGU9 SU5UIE92ZXJyaWRlCglCVVM9MAoJSVJRPTAKCUlOVFI9MgoJRmxhZ3M9e1BvbGFyaXR5PWNvbmZv cm1pbmcsIFRyaWdnZXI9Y29uZm9ybWluZ30KCglUeXBlPUlOVCBPdmVycmlkZQoJQlVTPTAKCUlS UT05CglJTlRSPTkKCUZsYWdzPXtQb2xhcml0eT1hY3RpdmUtaGksIFRyaWdnZXI9bGV2ZWx9CgoJ VHlwZT1Mb2NhbCBBUElDIE5NSQoJQUNQSSBDUFU9MQoJTElOVCBQaW49MQoJRmxhZ3M9e1BvbGFy aXR5PWFjdGl2ZS1oaSwgVHJpZ2dlcj1lZGdlfQoKCVR5cGU9TG9jYWwgQVBJQyBOTUkKCUFDUEkg Q1BVPTIKCUxJTlQgUGluPTEKCUZsYWdzPXtQb2xhcml0eT1hY3RpdmUtaGksIFRyaWdnZXI9ZWRn ZX0KCglUeXBlPUxvY2FsIEFQSUMgTk1JCglBQ1BJIENQVT0zCglMSU5UIFBpbj0xCglGbGFncz17 UG9sYXJpdHk9YWN0aXZlLWhpLCBUcmlnZ2VyPWVkZ2V9CgoJVHlwZT1Mb2NhbCBBUElDIE5NSQoJ QUNQSSBDUFU9NAoJTElOVCBQaW49MQoJRmxhZ3M9e1BvbGFyaXR5PWFjdGl2ZS1oaSwgVHJpZ2dl cj1lZGdlfQoKCVR5cGU9TG9jYWwgQVBJQyBOTUkKCUFDUEkgQ1BVPTUKCUxJTlQgUGluPTEKCUZs YWdzPXtQb2xhcml0eT1hY3RpdmUtaGksIFRyaWdnZXI9ZWRnZX0KCglUeXBlPUxvY2FsIEFQSUMg Tk1JCglBQ1BJIENQVT02CglMSU5UIFBpbj0xCglGbGFncz17UG9sYXJpdHk9YWN0aXZlLWhpLCBU cmlnZ2VyPWVkZ2V9CgoJVHlwZT1Mb2NhbCBBUElDIE5NSQoJQUNQSSBDUFU9NwoJTElOVCBQaW49 MQoJRmxhZ3M9e1BvbGFyaXR5PWFjdGl2ZS1oaSwgVHJpZ2dlcj1lZGdlfQoKCVR5cGU9TG9jYWwg QVBJQyBOTUkKCUFDUEkgQ1BVPTgKCUxJTlQgUGluPTEKCUZsYWdzPXtQb2xhcml0eT1hY3RpdmUt aGksIFRyaWdnZXI9ZWRnZX0KCglUeXBlPUxvY2FsIEFQSUMgTk1JCglBQ1BJIENQVT05CglMSU5U IFBpbj0xCglGbGFncz17UG9sYXJpdHk9YWN0aXZlLWhpLCBUcmlnZ2VyPWVkZ2V9CgoJVHlwZT1M b2NhbCBBUElDIE5NSQoJQUNQSSBDUFU9MTAKCUxJTlQgUGluPTEKCUZsYWdzPXtQb2xhcml0eT1h Y3RpdmUtaGksIFRyaWdnZXI9ZWRnZX0KCglUeXBlPUxvY2FsIEFQSUMgTk1JCglBQ1BJIENQVT0x MQoJTElOVCBQaW49MQoJRmxhZ3M9e1BvbGFyaXR5PWFjdGl2ZS1oaSwgVHJpZ2dlcj1lZGdlfQoK CVR5cGU9TG9jYWwgQVBJQyBOTUkKCUFDUEkgQ1BVPTEyCglMSU5UIFBpbj0xCglGbGFncz17UG9s YXJpdHk9YWN0aXZlLWhpLCBUcmlnZ2VyPWVkZ2V9CgoJVHlwZT1Mb2NhbCBBUElDIE5NSQoJQUNQ SSBDUFU9MTMKCUxJTlQgUGluPTEKCUZsYWdzPXtQb2xhcml0eT1hY3RpdmUtaGksIFRyaWdnZXI9 ZWRnZX0KCglUeXBlPUxvY2FsIEFQSUMgTk1JCglBQ1BJIENQVT0xNAoJTElOVCBQaW49MQoJRmxh Z3M9e1BvbGFyaXR5PWFjdGl2ZS1oaSwgVHJpZ2dlcj1lZGdlfQoKCVR5cGU9TG9jYWwgQVBJQyBO TUkKCUFDUEkgQ1BVPTE1CglMSU5UIFBpbj0xCglGbGFncz17UG9sYXJpdHk9YWN0aXZlLWhpLCBU cmlnZ2VyPWVkZ2V9CgoJVHlwZT1Mb2NhbCBBUElDIE5NSQoJQUNQSSBDUFU9MTYKCUxJTlQgUGlu PTEKCUZsYWdzPXtQb2xhcml0eT1hY3RpdmUtaGksIFRyaWdnZXI9ZWRnZX0KICovCi8qCiAgTkhM VDogTGVuZ3RoPTcwNDQsIFJldmlzaW9uPTAsIENoZWNrc3VtPTExMywKCU9FTUlEPUhQUU9FTSwg T0VNIFRhYmxlIElEPTg3MDksIE9FTSBSZXZpc2lvbj0weDEwNzIwMDksCglDcmVhdG9yIElEPUhQ LCBDcmVhdG9yIFJldmlzaW9uPTB4MTAwMDAxMwogKi8KLyoKICBMUElUOiBMZW5ndGg9MjA0LCBS ZXZpc2lvbj0xLCBDaGVja3N1bT0xMjUsCglPRU1JRD1IUFFPRU0sIE9FTSBUYWJsZSBJRD04NzA5 LCBPRU0gUmV2aXNpb249MHgxMDcyMDA5LAoJQ3JlYXRvciBJRD1IUCwgQ3JlYXRvciBSZXZpc2lv bj0weDEwMDAwMTMKCglUeXBlPUFDUElfTFBJVF9UWVBFX05BVElWRV9DU1RBVEUKCUxlbmd0aD01 NgoJVW5pcXVlSWQ9MHgwMDAwCglGbGFncz0KCUVudHJ5VHJpZ2dlcj0weDAwMDAwMDAwMDAwMDAw NjAgKD8pCglSZXNpZGVuY3k9MzAwMDAKCUxhdGVuY3k9MzAwMAoJUmVzaWRlbmN5Q291bnRlcj0w eDAwMDAwMDAwMDAwMDA2MzIgKD8pCglDb3VudGVyRnJlcXVlbmN5PVRTQwoKCVR5cGU9QUNQSV9M UElUX1RZUEVfTkFUSVZFX0NTVEFURQoJTGVuZ3RoPTU2CglVbmlxdWVJZD0weDAwMDEKCUZsYWdz PQoJRW50cnlUcmlnZ2VyPTB4MDAwMDAwMDAwMDAwMDA2MCAoPykKCVJlc2lkZW5jeT0zMDAwMAoJ TGF0ZW5jeT0zMDAwCglSZXNpZGVuY3lDb3VudGVyPTB4MDAwMDAwMDBmZTAwMTkzYzowWzMyXSAo TWVtb3J5KQoJQ291bnRlckZyZXF1ZW5jeT04MTk3CgoJVHlwZT1BQ1BJX0xQSVRfVFlQRV9OQVRJ VkVfQ1NUQVRFCglMZW5ndGg9NTYKCVVuaXF1ZUlkPTB4MDAwMgoJRmxhZ3M9e1NUQVRFX0RJU0FC TEVEfQoJRW50cnlUcmlnZ2VyPTB4MDAwMDAwMDAwMDAwMDA2MCAoPykKCVJlc2lkZW5jeT0zMDAw MAoJTGF0ZW5jeT0zMDAwCglSZXNpZGVuY3lDb3VudGVyPTB4MDAwMDAwMDAwMDAwMDBmZjowWzMy XSAoTWVtb3J5KQoJQ291bnRlckZyZXF1ZW5jeT1UU0MKICovCi8qCiAgU1NEVDogTGVuZ3RoPTEw MDE2LCBSZXZpc2lvbj0yLCBDaGVja3N1bT0zOCwKCU9FTUlEPUhQUU9FTSwgT0VNIFRhYmxlIElE PTg3MDksIE9FTSBSZXZpc2lvbj0weDEwMDAsCglDcmVhdG9yIElEPUFDUEksIENyZWF0b3IgUmV2 aXNpb249MHgyMDE5MTAxOAogKi8KLyoKICBTU0RUOiBMZW5ndGg9Mjk4LCBSZXZpc2lvbj0yLCBD aGVja3N1bT0yNDAsCglPRU1JRD1IUFFPRU0sIE9FTSBUYWJsZSBJRD04NzA5LCBPRU0gUmV2aXNp b249MHgwLAoJQ3JlYXRvciBJRD1BQ1BJLCBDcmVhdG9yIFJldmlzaW9uPTB4MjAxOTEwMTgKICov Ci8qCiAgREJHUDogTGVuZ3RoPTUyLCBSZXZpc2lvbj0xLCBDaGVja3N1bT0xNjgsCglPRU1JRD1I UFFPRU0sIE9FTSBUYWJsZSBJRD04NzA5LCBPRU0gUmV2aXNpb249MHgxMDcyMDA5LAoJQ3JlYXRv ciBJRD1IUCwgQ3JlYXRvciBSZXZpc2lvbj0weDEwMDAwMTMKICovCi8qCiAgREJHMjogTGVuZ3Ro PTg0LCBSZXZpc2lvbj0wLCBDaGVja3N1bT0yNDksCglPRU1JRD1IUFFPRU0sIE9FTSBUYWJsZSBJ RD04NzA5LCBPRU0gUmV2aXNpb249MHgxMDcyMDA5LAoJQ3JlYXRvciBJRD1IUCwgQ3JlYXRvciBS ZXZpc2lvbj0weDEwMDAwMTMKICovCi8qCiAgU1NEVDogTGVuZ3RoPTI5ODAsIFJldmlzaW9uPTIs IENoZWNrc3VtPTEwMCwKCU9FTUlEPUhQUU9FTSwgT0VNIFRhYmxlIElEPTg3MDksIE9FTSBSZXZp c2lvbj0weDEwMDAsCglDcmVhdG9yIElEPUFDUEksIENyZWF0b3IgUmV2aXNpb249MHgyMDE5MTAx OAogKi8KLyoKICBETUFSOiBMZW5ndGg9MTg0LCBSZXZpc2lvbj0yLCBDaGVja3N1bT0xOTEsCglP RU1JRD1IUFFPRU0sIE9FTSBUYWJsZSBJRD04NzA5LCBPRU0gUmV2aXNpb249MHgyLAoJQ3JlYXRv ciBJRD1IUCwgQ3JlYXRvciBSZXZpc2lvbj0weDEwMDAwMTMKCUhvc3QgQWRkcmVzcyBXaWR0aD0z OQoJRmxhZ3M9e0lOVFJfUkVNQVB9CgoJVHlwZT1EUkhECglMZW5ndGg9MjQKCUZsYWdzPQoJU2Vn bWVudD0wCglBZGRyZXNzPTB4MDAwMDAwMDBmZWQ5MDAwMAoJRGV2aWNlIFNjb3BlOgoJCVR5cGU9 UENJIEVuZHBvaW50IERldmljZQoJCUxlbmd0aD04CgkJRW51bWVyYXRpb25JZD0wCgkJU3RhcnRC dXNOdW1iZXI9MAoJCVBhdGg9ezI6MH0KCglUeXBlPURSSEQKCUxlbmd0aD0yNAoJRmxhZ3M9CglT ZWdtZW50PTAKCUFkZHJlc3M9MHgwMDAwMDAwMGZlZDg0MDAwCglEZXZpY2UgU2NvcGU6CgkJVHlw ZT1QQ0kgU3ViLUhpZXJhcmNoeQoJCUxlbmd0aD04CgkJRW51bWVyYXRpb25JZD0wCgkJU3RhcnRC dXNOdW1iZXI9MAoJCVBhdGg9ezc6MH0KCglUeXBlPURSSEQKCUxlbmd0aD0yNAoJRmxhZ3M9CglT ZWdtZW50PTAKCUFkZHJlc3M9MHgwMDAwMDAwMGZlZDg1MDAwCglEZXZpY2UgU2NvcGU6CgkJVHlw ZT1QQ0kgU3ViLUhpZXJhcmNoeQoJCUxlbmd0aD04CgkJRW51bWVyYXRpb25JZD0wCgkJU3RhcnRC dXNOdW1iZXI9MAoJCVBhdGg9ezc6MX0KCglUeXBlPURSSEQKCUxlbmd0aD0zMgoJRmxhZ3M9e0lO Q0xVREVfQUxMfQoJU2VnbWVudD0wCglBZGRyZXNzPTB4MDAwMDAwMDBmZWQ5MTAwMAoJRGV2aWNl IFNjb3BlOgoJCVR5cGU9SU9BUElDCgkJTGVuZ3RoPTgKCQlFbnVtZXJhdGlvbklkPTIKCQlTdGFy dEJ1c051bWJlcj0wCgkJUGF0aD17MzA6N30KCgkJVHlwZT1IUEVUCgkJTGVuZ3RoPTgKCQlFbnVt ZXJhdGlvbklkPTAKCQlTdGFydEJ1c051bWJlcj0wCgkJUGF0aD17MzA6Nn0KCglUeXBlPVJNUlIK CUxlbmd0aD0zMgoJU2VnbWVudD0wCglCYXNlQWRkcmVzcz0weDAwMDAwMDAwNjQwMDAwMDAKCUxp bWl0QWRkcmVzcz0weDAwMDAwMDAwNjgzZmZmZmYKCURldmljZSBTY29wZToKCQlUeXBlPVBDSSBF bmRwb2ludCBEZXZpY2UKCQlMZW5ndGg9OAoJCUVudW1lcmF0aW9uSWQ9MAoJCVN0YXJ0QnVzTnVt YmVyPTAKCQlQYXRoPXsyOjB9CiAqLwovKgogIFNTRFQ6IExlbmd0aD0xNjg1LCBSZXZpc2lvbj0y LCBDaGVja3N1bT0xNDMsCglPRU1JRD1IUFFPRU0sIE9FTSBUYWJsZSBJRD04NzA5LCBPRU0gUmV2 aXNpb249MHgwLAoJQ3JlYXRvciBJRD1BQ1BJLCBDcmVhdG9yIFJldmlzaW9uPTB4MjAxOTEwMTgK ICovCi8qCiAgU1NEVDogTGVuZ3RoPTMyNCwgUmV2aXNpb249MiwgQ2hlY2tzdW09ODYsCglPRU1J RD1IUFFPRU0sIE9FTSBUYWJsZSBJRD04NzA5LCBPRU0gUmV2aXNpb249MHgxMDAwLAoJQ3JlYXRv ciBJRD1BQ1BJLCBDcmVhdG9yIFJldmlzaW9uPTB4MjAxOTEwMTgKICovCi8qCiAgU1NEVDogTGVu Z3RoPTE1NywgUmV2aXNpb249MSwgQ2hlY2tzdW09NzEsCglPRU1JRD1IUFFPRU0sIE9FTSBUYWJs ZSBJRD04NzA5LCBPRU0gUmV2aXNpb249MHgxLAoJQ3JlYXRvciBJRD1BQ1BJLCBDcmVhdG9yIFJl dmlzaW9uPTB4MjAxOTEwMTgKICovCi8qCiAgU1NEVDogTGVuZ3RoPTk2LCBSZXZpc2lvbj0xLCBD aGVja3N1bT0yMjQsCglPRU1JRD1IUFFPRU0sIE9FTSBUYWJsZSBJRD04NzA5LCBPRU0gUmV2aXNp b249MHgxLAoJQ3JlYXRvciBJRD1BQ1BJLCBDcmVhdG9yIFJldmlzaW9uPTB4MjAxOTEwMTgKICov Ci8qCiAgVUVGSTogTGVuZ3RoPTE1OTQsIFJldmlzaW9uPTEsIENoZWNrc3VtPTE2OSwKCU9FTUlE PUhQUU9FTSwgT0VNIFRhYmxlIElEPTg3MDksIE9FTSBSZXZpc2lvbj0weDAsCglDcmVhdG9yIElE PUhQLCBDcmVhdG9yIFJldmlzaW9uPTB4MAogKi8KLyoKICBVRUZJOiBMZW5ndGg9OTIsIFJldmlz aW9uPTEsIENoZWNrc3VtPTg0LAoJT0VNSUQ9SFBRT0VNLCBPRU0gVGFibGUgSUQ9ODcwOSwgT0VN IFJldmlzaW9uPTB4MCwKCUNyZWF0b3IgSUQ9SFAsIENyZWF0b3IgUmV2aXNpb249MHgwCiAqLwov KgogIFRQTTI6IExlbmd0aD03NiwgUmV2aXNpb249NCwgQ2hlY2tzdW09MjQ1LAoJT0VNSUQ9SFBR T0VNLCBPRU0gVGFibGUgSUQ9ODcwOSwgT0VNIFJldmlzaW9uPTB4MSwKCUNyZWF0b3IgSUQ9SFAs IENyZWF0b3IgUmV2aXNpb249MHgwCgkJQ29udHJvbEFyZWE9MAoJCVN0YXJ0TWV0aG9kPTYKICov Ci8qCiAgU1NEVDogTGVuZ3RoPTQ1NTUyLCBSZXZpc2lvbj0yLCBDaGVja3N1bT0yMzEsCglPRU1J RD1IUFFPRU0sIE9FTSBUYWJsZSBJRD04NzA5LCBPRU0gUmV2aXNpb249MHgxMDAwLAoJQ3JlYXRv ciBJRD1BQ1BJLCBDcmVhdG9yIFJldmlzaW9uPTB4MjAxOTEwMTgKICovCi8qCiAgU1NEVDogTGVu Z3RoPTExMDk3LCBSZXZpc2lvbj0yLCBDaGVja3N1bT0xMzgsCglPRU1JRD1IUFFPRU0sIE9FTSBU YWJsZSBJRD04NzA5LCBPRU0gUmV2aXNpb249MHgzMDAwLAoJQ3JlYXRvciBJRD1BQ1BJLCBDcmVh dG9yIFJldmlzaW9uPTB4MjAxOTEwMTgKICovCi8qCiAgUFREVDogTGVuZ3RoPTMzMjYsIFJldmlz aW9uPTAsIENoZWNrc3VtPTEyNiwKCU9FTUlEPUhQUU9FTSwgT0VNIFRhYmxlIElEPTg3MDksIE9F TSBSZXZpc2lvbj0weDUsCglDcmVhdG9yIElEPUhQLCBDcmVhdG9yIFJldmlzaW9uPTB4MTAwMDAw ZAogKi8KLyoKICBXU01UOiBMZW5ndGg9NDAsIFJldmlzaW9uPTEsIENoZWNrc3VtPTcwLAoJT0VN SUQ9SFBRT0VNLCBPRU0gVGFibGUgSUQ9ODcwOSwgT0VNIFJldmlzaW9uPTB4MTA3MjAwOSwKCUNy ZWF0b3IgSUQ9SFAsIENyZWF0b3IgUmV2aXNpb249MHgxMDAxMwogKi8KLyoKICBGUERUOiBMZW5n dGg9NjgsIFJldmlzaW9uPTEsIENoZWNrc3VtPTE1LAoJT0VNSUQ9SFBRT0VNLCBPRU0gVGFibGUg SUQ9ODcwOSwgT0VNIFJldmlzaW9uPTB4MTA3MjAwOSwKCUNyZWF0b3IgSUQ9SFAsIENyZWF0b3Ig UmV2aXNpb249MHgxMDAwMDEzCiAqLwovKgogIEJHUlQ6IExlbmd0aD01NiwgUmV2aXNpb249MSwg Q2hlY2tzdW09MjA1LAoJT0VNSUQ9SFBRT0VNLCBPRU0gVGFibGUgSUQ9ODcwOSwgT0VNIFJldmlz aW9uPTB4MTA3MjAwOSwKCUNyZWF0b3IgSUQ9SFAsIENyZWF0b3IgUmV2aXNpb249MHgxMDAxMwog Ki8K --=_7d45d6f8fa0f7ae54fef89b375820143 Content-Transfer-Encoding: base64 Content-Type: text/plain; name=pcidump.txt Content-Disposition: attachment; filename=pcidump.txt; size=5467 aG9zdGIwQHBjaTA6MDowOjA6CWNsYXNzPTB4MDYwMDAwIHJldj0weDAxIGhkcj0weDAwIHZlbmRv cj0weDgwODYgZGV2aWNlPTB4OWExNCBzdWJ2ZW5kb3I9MHgxMDNjIHN1YmRldmljZT0weDg3MDkK ICAgIHZlbmRvciAgICAgPSAnSW50ZWwgQ29ycG9yYXRpb24nCiAgICBkZXZpY2UgICAgID0gJzEx dGggR2VuIENvcmUgUHJvY2Vzc29yIEhvc3QgQnJpZGdlL0RSQU0gUmVnaXN0ZXJzJwogICAgY2xh c3MgICAgICA9IGJyaWRnZQogICAgc3ViY2xhc3MgICA9IEhPU1QtUENJCnZnYXBjaTBAcGNpMDow OjI6MDoJY2xhc3M9MHgwMzAwMDAgcmV2PTB4MDEgaGRyPTB4MDAgdmVuZG9yPTB4ODA4NiBkZXZp Y2U9MHg5YTQ5IHN1YnZlbmRvcj0weDEwM2Mgc3ViZGV2aWNlPTB4ODcwOQogICAgdmVuZG9yICAg ICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGRldmljZSAgICAgPSAnVUhEIEdyYXBoaWNzJwog ICAgY2xhc3MgICAgICA9IGRpc3BsYXkKICAgIHN1YmNsYXNzICAgPSBWR0EKbm9uZTBAcGNpMDow OjQ6MDoJY2xhc3M9MHgxMTgwMDAgcmV2PTB4MDEgaGRyPTB4MDAgdmVuZG9yPTB4ODA4NiBkZXZp Y2U9MHg5YTAzIHN1YnZlbmRvcj0weDEwM2Mgc3ViZGV2aWNlPTB4ODcwOQogICAgdmVuZG9yICAg ICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGNsYXNzICAgICAgPSBkYXNwCnBjaWIxQHBjaTA6 MDo3OjA6CWNsYXNzPTB4MDYwNDAwIHJldj0weDAxIGhkcj0weDAxIHZlbmRvcj0weDgwODYgZGV2 aWNlPTB4OWEyMyBzdWJ2ZW5kb3I9MHgxMDNjIHN1YmRldmljZT0weDg3MDkKICAgIHZlbmRvciAg ICAgPSAnSW50ZWwgQ29ycG9yYXRpb24nCiAgICBkZXZpY2UgICAgID0gJ1RpZ2VyIExha2UtTFAg VGh1bmRlcmJvbHQgUENJIEV4cHJlc3MgUm9vdCBQb3J0JwogICAgY2xhc3MgICAgICA9IGJyaWRn ZQogICAgc3ViY2xhc3MgICA9IFBDSS1QQ0kKcGNpYjJAcGNpMDowOjc6MToJY2xhc3M9MHgwNjA0 MDAgcmV2PTB4MDEgaGRyPTB4MDEgdmVuZG9yPTB4ODA4NiBkZXZpY2U9MHg5YTI1IHN1YnZlbmRv cj0weDEwM2Mgc3ViZGV2aWNlPTB4ODcwOQogICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3Jh dGlvbicKICAgIGRldmljZSAgICAgPSAnVGlnZXIgTGFrZS1MUCBUaHVuZGVyYm9sdCBQQ0kgRXhw cmVzcyBSb290IFBvcnQnCiAgICBjbGFzcyAgICAgID0gYnJpZGdlCiAgICBzdWJjbGFzcyAgID0g UENJLVBDSQpub25lMUBwY2kwOjA6ODowOgljbGFzcz0weDA4ODAwMCByZXY9MHgwMSBoZHI9MHgw MCB2ZW5kb3I9MHg4MDg2IGRldmljZT0weDlhMTEgc3VidmVuZG9yPTB4MTAzYyBzdWJkZXZpY2U9 MHg4NzA5CiAgICB2ZW5kb3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAgY2xhc3MgICAg ICA9IGJhc2UgcGVyaXBoZXJhbAp4aGNpMEBwY2kwOjA6MTM6MDoJY2xhc3M9MHgwYzAzMzAgcmV2 PTB4MDEgaGRyPTB4MDAgdmVuZG9yPTB4ODA4NiBkZXZpY2U9MHg5YTEzIHN1YnZlbmRvcj0weDEw M2Mgc3ViZGV2aWNlPTB4ODcwOQogICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicK ICAgIGRldmljZSAgICAgPSAnVGlnZXIgTGFrZS1MUCBUaHVuZGVyYm9sdCBVU0IgQ29udHJvbGxl cicKICAgIGNsYXNzICAgICAgPSBzZXJpYWwgYnVzCiAgICBzdWJjbGFzcyAgID0gVVNCCm5vbmUy QHBjaTA6MDoxMzoyOgljbGFzcz0weDBjMDM0MCByZXY9MHgwMSBoZHI9MHgwMCB2ZW5kb3I9MHg4 MDg2IGRldmljZT0weDlhMWIgc3VidmVuZG9yPTB4MDAwMCBzdWJkZXZpY2U9MHgwMDAwCiAgICB2 ZW5kb3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAgZGV2aWNlICAgICA9ICdUaWdlciBM YWtlLUxQIFRodW5kZXJib2x0IE5ISScKICAgIGNsYXNzICAgICAgPSBzZXJpYWwgYnVzCiAgICBz dWJjbGFzcyAgID0gVVNCCm5vbmUzQHBjaTA6MDoxNDowOgljbGFzcz0weDAxMDQwMCByZXY9MHgw MCBoZHI9MHgwMCB2ZW5kb3I9MHg4MDg2IGRldmljZT0weDlhMGIgc3VidmVuZG9yPTB4ODA4NiBz dWJkZXZpY2U9MHgwMDAwCiAgICB2ZW5kb3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAg ZGV2aWNlICAgICA9ICdWb2x1bWUgTWFuYWdlbWVudCBEZXZpY2UgTlZNZSBSQUlEIENvbnRyb2xs ZXInCiAgICBjbGFzcyAgICAgID0gbWFzcyBzdG9yYWdlCiAgICBzdWJjbGFzcyAgID0gUkFJRApu b25lNEBwY2kwOjA6MTg6MDoJY2xhc3M9MHgwNzAwMDAgcmV2PTB4MjAgaGRyPTB4MDAgdmVuZG9y PTB4ODA4NiBkZXZpY2U9MHhhMGZjIHN1YnZlbmRvcj0weDEwM2Mgc3ViZGV2aWNlPTB4ODcwOQog ICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGRldmljZSAgICAgPSAnVGln ZXIgTGFrZS1MUCBJbnRlZ3JhdGVkIFNlbnNvciBIdWInCiAgICBjbGFzcyAgICAgID0gc2ltcGxl IGNvbW1zCiAgICBzdWJjbGFzcyAgID0gVUFSVAp4aGNpMUBwY2kwOjA6MjA6MDoJY2xhc3M9MHgw YzAzMzAgcmV2PTB4MjAgaGRyPTB4MDAgdmVuZG9yPTB4ODA4NiBkZXZpY2U9MHhhMGVkIHN1YnZl bmRvcj0weDEwM2Mgc3ViZGV2aWNlPTB4ODcwOQogICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jw b3JhdGlvbicKICAgIGRldmljZSAgICAgPSAnVGlnZXIgTGFrZS1MUCBVU0IgMy4yIEdlbiAyeDEg eEhDSSBIb3N0IENvbnRyb2xsZXInCiAgICBjbGFzcyAgICAgID0gc2VyaWFsIGJ1cwogICAgc3Vi Y2xhc3MgICA9IFVTQgpub25lNUBwY2kwOjA6MjA6MjoJY2xhc3M9MHgwNTAwMDAgcmV2PTB4MjAg aGRyPTB4MDAgdmVuZG9yPTB4ODA4NiBkZXZpY2U9MHhhMGVmIHN1YnZlbmRvcj0weDEwM2Mgc3Vi ZGV2aWNlPTB4ODcwOQogICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGRl dmljZSAgICAgPSAnVGlnZXIgTGFrZS1MUCBTaGFyZWQgU1JBTScKICAgIGNsYXNzICAgICAgPSBt ZW1vcnkKICAgIHN1YmNsYXNzICAgPSBSQU0Kbm9uZTZAcGNpMDowOjIwOjM6CWNsYXNzPTB4MDI4 MDAwIHJldj0weDIwIGhkcj0weDAwIHZlbmRvcj0weDgwODYgZGV2aWNlPTB4YTBmMCBzdWJ2ZW5k b3I9MHg4MDg2IHN1YmRldmljZT0weDAwNzQKICAgIHZlbmRvciAgICAgPSAnSW50ZWwgQ29ycG9y YXRpb24nCiAgICBkZXZpY2UgICAgID0gJ1dpLUZpIDYgQVgyMDEnCiAgICBjbGFzcyAgICAgID0g bmV0d29yawppZzRpaWMwQHBjaTA6MDoyMTowOgljbGFzcz0weDBjODAwMCByZXY9MHgyMCBoZHI9 MHgwMCB2ZW5kb3I9MHg4MDg2IGRldmljZT0weGEwZTggc3VidmVuZG9yPTB4MTAzYyBzdWJkZXZp Y2U9MHg4NzA5CiAgICB2ZW5kb3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAgZGV2aWNl ICAgICA9ICdUaWdlciBMYWtlLUxQIFNlcmlhbCBJTyBJMkMgQ29udHJvbGxlcicKICAgIGNsYXNz ICAgICAgPSBzZXJpYWwgYnVzCmlnNGlpYzFAcGNpMDowOjIxOjE6CWNsYXNzPTB4MGM4MDAwIHJl dj0weDIwIGhkcj0weDAwIHZlbmRvcj0weDgwODYgZGV2aWNlPTB4YTBlOSBzdWJ2ZW5kb3I9MHgx MDNjIHN1YmRldmljZT0weDg3MDkKICAgIHZlbmRvciAgICAgPSAnSW50ZWwgQ29ycG9yYXRpb24n CiAgICBkZXZpY2UgICAgID0gJ1RpZ2VyIExha2UtTFAgU2VyaWFsIElPIEkyQyBDb250cm9sbGVy JwogICAgY2xhc3MgICAgICA9IHNlcmlhbCBidXMKbm9uZTdAcGNpMDowOjIyOjA6CWNsYXNzPTB4 MDc4MDAwIHJldj0weDIwIGhkcj0weDAwIHZlbmRvcj0weDgwODYgZGV2aWNlPTB4YTBlMCBzdWJ2 ZW5kb3I9MHgxMDNjIHN1YmRldmljZT0weDg3MDkKICAgIHZlbmRvciAgICAgPSAnSW50ZWwgQ29y cG9yYXRpb24nCiAgICBkZXZpY2UgICAgID0gJ1RpZ2VyIExha2UtTFAgTWFuYWdlbWVudCBFbmdp bmUgSW50ZXJmYWNlJwogICAgY2xhc3MgICAgICA9IHNpbXBsZSBjb21tcwpwY2liM0BwY2kwOjA6 Mjg6MDoJY2xhc3M9MHgwNjA0MDAgcmV2PTB4MjAgaGRyPTB4MDEgdmVuZG9yPTB4ODA4NiBkZXZp Y2U9MHhhMGJkIHN1YnZlbmRvcj0weDEwM2Mgc3ViZGV2aWNlPTB4ODcwOQogICAgdmVuZG9yICAg ICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGNsYXNzICAgICAgPSBicmlkZ2UKICAgIHN1YmNs YXNzICAgPSBQQ0ktUENJCm5vbmU4QHBjaTA6MDoyOTowOgljbGFzcz0weDA4ODAwMCByZXY9MHgw MCBoZHI9MHgwMCB2ZW5kb3I9MHg4MDg2IGRldmljZT0weDA5YWIgc3VidmVuZG9yPTB4MTAzYyBz dWJkZXZpY2U9MHg4NzA5CiAgICB2ZW5kb3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAg Y2xhc3MgICAgICA9IGJhc2UgcGVyaXBoZXJhbAppc2FiMEBwY2kwOjA6MzE6MDoJY2xhc3M9MHgw NjAxMDAgcmV2PTB4MjAgaGRyPTB4MDAgdmVuZG9yPTB4ODA4NiBkZXZpY2U9MHhhMDgyIHN1YnZl bmRvcj0weDEwM2Mgc3ViZGV2aWNlPTB4ODcwOQogICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jw b3JhdGlvbicKICAgIGRldmljZSAgICAgPSAnVGlnZXIgTGFrZS1MUCBMUEMgQ29udHJvbGxlcicK ICAgIGNsYXNzICAgICAgPSBicmlkZ2UKICAgIHN1YmNsYXNzICAgPSBQQ0ktSVNBCmhkYWMwQHBj aTA6MDozMTozOgljbGFzcz0weDA0MDEwMCByZXY9MHgyMCBoZHI9MHgwMCB2ZW5kb3I9MHg4MDg2 IGRldmljZT0weGEwYzggc3VidmVuZG9yPTB4MTAzYyBzdWJkZXZpY2U9MHg4NzA5CiAgICB2ZW5k b3IgICAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAgZGV2aWNlICAgICA9ICdUaWdlciBMYWtl LUxQIFNtYXJ0IFNvdW5kIFRlY2hub2xvZ3kgQXVkaW8gQ29udHJvbGxlcicKICAgIGNsYXNzICAg ICAgPSBtdWx0aW1lZGlhCiAgICBzdWJjbGFzcyAgID0gYXVkaW8KaWNoc21iMEBwY2kwOjA6MzE6 NDoJY2xhc3M9MHgwYzA1MDAgcmV2PTB4MjAgaGRyPTB4MDAgdmVuZG9yPTB4ODA4NiBkZXZpY2U9 MHhhMGEzIHN1YnZlbmRvcj0weDEwM2Mgc3ViZGV2aWNlPTB4ODcwOQogICAgdmVuZG9yICAgICA9 ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGRldmljZSAgICAgPSAnVGlnZXIgTGFrZS1MUCBTTUJ1 cyBDb250cm9sbGVyJwogICAgY2xhc3MgICAgICA9IHNlcmlhbCBidXMKICAgIHN1YmNsYXNzICAg PSBTTUJ1cwpub25lOUBwY2kwOjA6MzE6NToJY2xhc3M9MHgwYzgwMDAgcmV2PTB4MjAgaGRyPTB4 MDAgdmVuZG9yPTB4ODA4NiBkZXZpY2U9MHhhMGE0IHN1YnZlbmRvcj0weDEwM2Mgc3ViZGV2aWNl PTB4ODcwOQogICAgdmVuZG9yICAgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGRldmljZSAg ICAgPSAnVGlnZXIgTGFrZS1MUCBTUEkgQ29udHJvbGxlcicKICAgIGNsYXNzICAgICAgPSBzZXJp YWwgYnVzCnJ0c3gwQHBjaTA6ODc6MDowOgljbGFzcz0weGZmMDAwMCByZXY9MHgwMSBoZHI9MHgw MCB2ZW5kb3I9MHgxMGVjIGRldmljZT0weDUyNWEgc3VidmVuZG9yPTB4MTAzYyBzdWJkZXZpY2U9 MHg4NzA5CiAgICB2ZW5kb3IgICAgID0gJ1JlYWx0ZWsgU2VtaWNvbmR1Y3RvciBDby4sIEx0ZC4n CiAgICBkZXZpY2UgICAgID0gJ1JUUzUyNUEgUENJIEV4cHJlc3MgQ2FyZCBSZWFkZXInCg== --=_7d45d6f8fa0f7ae54fef89b375820143-- From owner-freebsd-current@freebsd.org Thu Dec 31 08:13: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 DEF954B8272 for ; Thu, 31 Dec 2020 08:13:37 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wr1-x42b.google.com (mail-wr1-x42b.google.com [IPv6:2a00:1450:4864:20::42b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature 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 4D61BT1sBmz4RVd for ; Thu, 31 Dec 2020 08:13:36 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: by mail-wr1-x42b.google.com with SMTP id r3so19498012wrt.2 for ; Thu, 31 Dec 2020 00:13:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=1J/tc0BwpAoxkhhuL0Vy0hKIdsGHlzyuwLFp0kB1WfE=; b=nX1S1udm+4yGe9ehu+AoIF/RwZxJYhyIRl6+laxKe2pPqPDtom2q1Bo1EKyoovRsyd 5K58vt/BLpFehX/uMaPBFxDmmnbnBVSkQ21acL1+UrYtQwC9bHjVCUkISRMDunvjCuCX /0NmQvc4IjQZ26qcJFhr/bv68nhzTwav7USqKkY45ZpJK2wuyAGv23nKGFZ3YT6BUugM VCygILgzgO9RXaVtQmbWy2AdO/RJxJpEEszAnrSoVtgsFnIzuf5eEWCvgIE347g3sWIp P3zolfhk8oxW9cCEBU5E3DuOsZDNjG6mPhISTinpZL7O5RIEDyaJAXvPKbw14WfNYhGf xm7w== X-Gm-Message-State: AOAM532WdRvpgv/6eU/bAN8EJO2vOhYISllW17QI9j/n5diLMHZEhJZB r8pdClx3p7fGxVLbCajXXNir5DezlAjuXg== X-Google-Smtp-Source: ABdhPJzT2gB8mVK5fmCtejSHOxoE0Kxo9muMPRq0+XGQxX2m9MPFjakyOLUAVhNIF/y+hLMI/o+xcA== X-Received: by 2002:adf:828b:: with SMTP id 11mr62056230wrc.180.1609402415410; Thu, 31 Dec 2020 00:13:35 -0800 (PST) Received: from [192.168.1.11] (79-66-147-78.dynamic.dsl.as9105.com. [79.66.147.78]) by smtp.gmail.com with ESMTPSA id l1sm71092741wrq.64.2020.12.31.00.13.34 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 31 Dec 2020 00:13:34 -0800 (PST) To: FreeBSD-CURRENT From: Graham Perrin Subject: drwxr-xr-x by default for automatically created mount points Message-ID: Date: Thu, 31 Dec 2020 08:13:34 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-Rspamd-Queue-Id: 4D61BT1sBmz4RVd X-Spamd-Bar: - X-Spamd-Result: default: False [-2.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RECEIVED_SPAMHAUS_PBL(0.00)[79.66.147.78:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a00:1450:4864:20::42b:from]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[2a00:1450:4864:20::42b:from:127.0.2.255]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::42b:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 31 Dec 2020 08:13:37 -0000 In brief (for example): grahamperrin@mowa219-gjp4-8570p:~ % ls -dhl /media/da1p1 drwxr-xr-x  3 root  wheel   512B 30 Dec 13:29 /media/da1p1 grahamperrin@mowa219-gjp4-8570p:~ % touch /media/da1p1/touched touch: /media/da1p1/touched: Permission denied – is drwxr-xr-x as a default the norm? In greater detail: From owner-freebsd-current@freebsd.org Thu Dec 31 11:40:18 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 215414BD9DE for ; Thu, 31 Dec 2020 11:40:18 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4D65mx6BCdz4dWD; Thu, 31 Dec 2020 11:40:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 0BVBe3tq060457 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 31 Dec 2020 13:40:06 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 0BVBe3tq060457 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 0BVBe3Lr060428; Thu, 31 Dec 2020 13:40:03 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 31 Dec 2020 13:40:03 +0200 From: Konstantin Belousov To: Rick Macklem Cc: "freebsd-current@freebsd.org" , Alan Somers , Kirk McKusick , Mark Johnston Subject: Re: r367672 broke the NFS server Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on tom.home X-Rspamd-Queue-Id: 4D65mx6BCdz4dWD X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 31 Dec 2020 11:40:18 -0000 On Thu, Dec 31, 2020 at 05:16:27AM +0000, Rick Macklem wrote: > Rick Macklem wrote: > >Kostik wrote: > > > > > >Idea of the change is to restart the syscall at top level. So for NFS > > >server the right approach is to not send a response and also to not > > >free the request mbuf chain, but to restart processing. > > Yes. I took a look and I think restarting the operation by rolling the > > working position in the mbuf lists back and redoing the operation > > is feasible and easier than fixing the individual operations. > > > > For NFSv4, you cannot redo the entire compound, since non-idempotent > > operations like exclusive open may have already been completed. > > However, rolling back to the beginning of the operation should be > > doable. > Turned out to be quite easy. I'll stick a patch up on phabricator > tomorrow, after I do a little more testing. > NFSv4.0 is still broken, because it screws up the seqid, but I can > fix that separately. > > I do see the code looping about 2-3 times before it gets a successful > ufs_create(). Does that sound reasonable? In the simple case, it could be described as is: ERELOOKUP is returned if the parent directory cannot be locked sleep-less, and we have to drop the lock for opened vnode to sleep on it. More elaborate (but still not precise) description is that parent directory might also need to be synced, in which case its parent might need to be locked, and so on recursively. Slightly reformulating, I expect that ERELOOKUPs come out in case several threads create files in the same directory. > Here's some debug printfs for the test run of 4 concurrent compiles. > (proc=8 is create and proc=12 is remove. Each line is a ERELOOKUP > retry. This is for the 4 threads, but I had the thread tid in another printf > and it showed 2-3 attempts for the same thread. They should be serialized > by the exclusive lock on the directory vnode.) I cannot make any conclusion from the output and its description. Are there opens that do not result in ERELOOKUP, i.e. does the op eventually succeed ? What is the ratio of ERELOOKUP vs. success ? Also note that any VOP that modify the volume' metadata might result in ERELOOKUP. > tryag3 stat=0 proc=8 > tryag3 stat=0 proc=8 From owner-freebsd-current@freebsd.org Thu Dec 31 18:33:38 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 1331A4CADC2 for ; Thu, 31 Dec 2020 18:33:38 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.netplex.net", Issuer "RapidSSL RSA CA 2018" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D6Gxs3kRhz3Q5T for ; Thu, 31 Dec 2020 18:33:37 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.15.1/8.15.1/NETPLEX) with ESMTP id 0BVIXPru017995 for ; Thu, 31 Dec 2020 13:33:30 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.4.3 (mail.netplex.net [204.213.176.9]); Thu, 31 Dec 2020 13:33:30 -0500 (EST) Date: Thu, 31 Dec 2020 13:33:25 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net Reply-To: Daniel Eischen To: freebsd-current@freebsd.org Subject: poudriere: services_mkdb recompile with larger PROTOMAX Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Rspamd-Queue-Id: 4D6Gxs3kRhz3Q5T X-Spamd-Bar: / X-Spamd-Result: default: False [0.00 / 15.00]; local_wl_from(0.00)[freebsd.org]; ASN(0.00)[asn:6062, ipnet:204.213.176.0/20, country:US] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 31 Dec 2020 18:33:38 -0000 I see this message in src/UPDATING: 20201216: The services database has been updated to cover more of the basic services expected in a modern system. The database is big enough that it will cause issues in mergemaster in Releases previous to 12.2 and 11.3, or in very old current systems from before r358154. I'm trying to update a poudriere jail from a freshly built -current system (r368820): FreeBSD vega.my.domain 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r368820 Wed Dec 30 15:55:06 EST 2020 I've tried running this command twice: export MAKEOBJDIRPREFIX=/opt/FreeBSD/obj/head.obj poudriere jail -u -j 13amd64 [ /opt/FreeBSD/obj/head.obj is my freshly built (r368820) obj tree is ] services_mkdb was updated in the jail on the first pass: # ls -l /usr/local/poudriere/jails/13amd64/usr/sbin/services_mkdb -r-xr-xr-x 1 root wheel 15288 Dec 31 13:02 /usr/local/poudriere/jails/13amd64/usr/sbin/services_mkdb But as on the first pass of 'poudriere jail -u -j 13amd64`, I still get the following error: ... --- _CONFSINS_services --- install -N /opt/FreeBSD/svn/head/etc -C -o root -g wheel -m 644 /opt/FreeBSD/svn/head/usr.sbin/services_mkdb/services /usr/local/poudriere/jails/13amd64/etc/services --- installconfig_subdir_usr.bin --- --- installconfig_subdir_usr.bin/nice --- ===> usr.bin/nice (installconfig) --- installconfig_subdir_usr.sbin --- --- afterinstallconfig --- --- installconfig_subdir_lib --- --- installconfig_subdir_lib/ncurses --- --- installconfig_subdir_lib/ncurses/ncurses --- ===> lib/ncurses/ncurses (installconfig) --- installconfig_subdir_usr.sbin --- services_mkdb -l -q -o /usr/local/poudriere/jails/13amd64/var/db/services.db /usr/local/poudriere/jails/13amd64/etc/services --- installconfig_subdir_usr.bin --- --- installconfig_subdir_usr.bin/nl --- ===> usr.bin/nl (installconfig) --- installconfig_subdir_usr.sbin --- services_mkdb: Ran out of protocols adding `divert'; recompile with larger PROTOMAX What's the work-around for this? services_mkdb seems to have been updated on the first pass off 'poudiere jail -u ...', but still fails on the second pass. -- DE From owner-freebsd-current@freebsd.org Thu Dec 31 19:39:17 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 D085D4CCBA5 for ; Thu, 31 Dec 2020 19:39:17 +0000 (UTC) (envelope-from jmg@gold.funkthat.com) Received: from gold.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gate2.funkthat.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D6JPc73ZSz3k3q for ; Thu, 31 Dec 2020 19:39:16 +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 0BVJd8u0080738 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 31 Dec 2020 11:39:08 -0800 (PST) (envelope-from jmg@gold.funkthat.com) Received: (from jmg@localhost) by gold.funkthat.com (8.15.2/8.15.2/Submit) id 0BVJd8VW080737; Thu, 31 Dec 2020 11:39:08 -0800 (PST) (envelope-from jmg) Date: Thu, 31 Dec 2020 11:39:08 -0800 From: John-Mark Gurney To: grarpamp Cc: freebsd-current@freebsd.org Subject: Re: HEADS UP: FreeBSD src repo transitioning to git this weekend Message-ID: <20201231193908.GC31099@funkthat.com> Mail-Followup-To: grarpamp , freebsd-current@freebsd.org References: <5fdc0b90.1c69fb81.866eb.8c29SMTPIN_ADDED_MISSING@mx.google.com> <20201218175241.GA72552@spindle.one-eyed-alien.net> <20201218182820.1P0tK%steffen@sdaoden.eu> <20201223023242.GG31099@funkthat.com> <20201223162417.v7Ce6%steffen@sdaoden.eu> <20201229011939.GU31099@funkthat.com> <20201229210454.Lh4y_%steffen@sdaoden.eu> <20201230004620.GB31099@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 11.3-STABLE amd64 X-PGP-Fingerprint: D87A 235F FB71 1F3F 55B7 ED9B D5FF 5A51 C0AC 3D65 X-Files: The truth is out there X-URL: https://www.funkthat.com/ X-Resume: https://www.funkthat.com/~jmg/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? User-Agent: Mutt/1.6.1 (2016-04-27) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (gold.funkthat.com [127.0.0.1]); Thu, 31 Dec 2020 11:39:09 -0800 (PST) X-Rspamd-Queue-Id: 4D6JPc73ZSz3k3q X-Spamd-Bar: / X-Spamd-Result: default: False [0.24 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[jmg]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[funkthat.com]; RBL_DBL_DONT_QUERY_IPS(0.00)[208.87.223.18:from]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; SPAMHAUS_ZRD(0.00)[208.87.223.18:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.96)[-0.964]; R_SPF_NA(0.00)[no SPF record]; FREEMAIL_TO(0.00)[gmail.com]; 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.34 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, 31 Dec 2020 19:39:17 -0000 grarpamp wrote this message on Wed, Dec 30, 2020 at 00:55 -0500: > > signatures of the magnet links > > Signing torrent.asc, with stronger or even same hash as BT > protocol, still serve purpose of authenticate torrent file back > to a signer to the degree therein, caveat their platform security, > caveat sha-1 inside torrent still being abuseable by third party, > caveat etc. With no torrent.asc there is nothing directly saying > the torrent file / infohash itself went through freebsd project. > Whether torrent or git or else, there can be useable scope > and case for such "stronger over weaker" constructions. There is already HTTPS to protect the "authenticity" of the magnet link. Yes, someone could vandalize the wiki page but I'm now subscribed and will notice it... Also, magnet links are not officially supported the project.. I provide them because I think it's useful, and there are some people who request them... One of the large parts of security is that not everyone knows the in's and out's of security, so people who don't know, will have heard that SHA-1 is a cryptographic hash, and assume that something is secure when using it. It's difficult to educate people on these points.. > gpg offers better hash algos than sha-1 these days, > all users should look into configuring and using it, > same goes for abandoning the old [a]symmetric algos > and weaker keys, made with old weak /dev/random, etc. > > One cannot sign or verify anything without knowing gpg first :) snapaid was designed to make it even easier... -- 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 Dec 31 19:51: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 CA07A4CD1B2 for ; Thu, 31 Dec 2020 19:51:13 +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 4D6JgP3rp8z3l7C for ; Thu, 31 Dec 2020 19:51:13 +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 974EF27BAE for ; Thu, 31 Dec 2020 19:51:07 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.10.3 tor1-11.mx.scaleengine.net 974EF27BAE To: FreeBSD Current From: Allan Jude Subject: Enabling AESNI by default Message-ID: <5d56280e-a8dd-b28d-7039-f8fe0bc0cd6f@freebsd.org> Date: Thu, 31 Dec 2020 14:51:06 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4D6JgP3rp8z3l7C X-Spamd-Bar: / X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; local_wl_from(0.00)[freebsd.org] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 31 Dec 2020 19:51:13 -0000 We've had the AESNI module for quite a few years now, and it has not caused any problems. I am wondering if there are any objections to including it in GENERIC, so that users get the benefit without having to have the "tribal knowledge" that 'to accelerate kernel crypto (GELI, ZFS, IPSEC, etc), you need to load aesni.ko' Userspace crypto that uses openssl or similar libraries is already taking advantage of these CPU instructions if they are available, by excluding this feature from GENERIC we are just causing the "out of the box" experience to by very very slow for crypto. For example, writing 1MB blocks to a GELI encrypted swap-backed md(4) device: with 8 jobs on a 10 core Intel Xeon CPU E5-2630 v4 @ 2.20GHz fio --filename=/dev/md0.eli --device=1 --name=geli --rw=write --bs=1m --numjobs=8 --iodepth=16 --end_fsync=1 --ioengine=pvsync --group_reporting --fallocate=none --runtime=60 --time_based stock: write: IOPS=530, BW=530MiB/s (556MB/s) (31.1GiB/60012msec) with aesni.ko loaded: write: IOPS=2824, BW=2825MiB/s (2962MB/s) (166GiB/60002msec) Does anyone have a compelling reason to deny our users the 5x speedup? -- Allan Jude From owner-freebsd-current@freebsd.org Thu Dec 31 20:07: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 E85884CDD58 for ; Thu, 31 Dec 2020 20:07:05 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qv1-xf2c.google.com (mail-qv1-xf2c.google.com [IPv6:2607:f8b0:4864:20::f2c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D6K1j1CXsz3mB3 for ; Thu, 31 Dec 2020 20:07:04 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qv1-xf2c.google.com with SMTP id p5so9362598qvs.7 for ; Thu, 31 Dec 2020 12:07:04 -0800 (PST) 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:references :mime-version:content-disposition:in-reply-to; bh=268ayWxWElyFO73Fadv1ILf+Bdr4fpE4R7GWAIvsYfI=; b=bWmIckKxyfyPBrJN55KQ++HBJSMLKsNaiwKjXOUlufVDfAdsBDO/AUotW9rgNchqjU 5qSrk5+7cgtiZp6H/rwrPoopSpzYye2MsRaIgPAVOBG2En/gRpjUUXSTtscn4Hy7do4q YPicjCbNK7pkwFK5iZuqmjCYNmt68uSyUsEBkrIrdjaseKRnfK9mvAYdFZq7x0NiPZN2 oeEOtrNdMevQb9szyYl0WkWpM1QlnWF/kB03eBR/RhMCAwL54eAENkGuu6GzGkWOUc90 rz5VWB/ouRZxuX0QAwm0xcdvVmUVO9SOaJmOUiDIF3luF7weuQ0zJrVXX0TuPtRFuS8i Fstg== X-Gm-Message-State: AOAM531eaNE8UjBDHT6q8kDbP/lbggylaTmJPqW7UQJXAzJUJeCQNsdk Q+ZSl8epE96RBo8eqmpFRU8CfsegSbyK9Q== X-Google-Smtp-Source: ABdhPJzf3ahz0swJl2XubT7edAIRpHGsINEAcrq4CQbVOut2f29SYycgZR4bgz/2IX/KFvSr45mZsw== X-Received: by 2002:ad4:5b82:: with SMTP id 2mr62722534qvp.28.1609445223929; Thu, 31 Dec 2020 12:07:03 -0800 (PST) Received: from mutt-hbsd (pool-100-16-222-53.bltmmd.fios.verizon.net. [100.16.222.53]) by smtp.gmail.com with ESMTPSA id f10sm30865526qtg.27.2020.12.31.12.07.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 31 Dec 2020 12:07:02 -0800 (PST) Date: Thu, 31 Dec 2020 15:07:02 -0500 From: Shawn Webb To: Allan Jude Cc: FreeBSD Current Subject: Re: Enabling AESNI by default Message-ID: <20201231200702.22gvepvlzfwncalz@mutt-hbsd> X-Operating-System: FreeBSD mutt-hbsd 13.0-CURRENT-HBSD FreeBSD 13.0-CURRENT-HBSD X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0xFF2E67A277F8E1FA References: <5d56280e-a8dd-b28d-7039-f8fe0bc0cd6f@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ji2eli3lbepfjcm2" Content-Disposition: inline In-Reply-To: <5d56280e-a8dd-b28d-7039-f8fe0bc0cd6f@freebsd.org> X-Rspamd-Queue-Id: 4D6K1j1CXsz3mB3 X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.10 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[hardenedbsd.org:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-1.000]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RBL_DBL_DONT_QUERY_IPS(0.00)[2607:f8b0:4864:20::f2c:from]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RECEIVED_SPAMHAUS_PBL(0.00)[100.16.222.53:received]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[hardenedbsd.org:s=google]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[hardenedbsd.org]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; SPAMHAUS_ZRD(0.00)[2607:f8b0:4864:20::f2c:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f2c:from]; MID_RHS_NOT_FQDN(0.50)[]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 31 Dec 2020 20:07:06 -0000 --ji2eli3lbepfjcm2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 31, 2020 at 02:51:06PM -0500, Allan Jude wrote: > We've had the AESNI module for quite a few years now, and it has not > caused any problems. >=20 > I am wondering if there are any objections to including it in GENERIC, > so that users get the benefit without having to have the "tribal > knowledge" that 'to accelerate kernel crypto (GELI, ZFS, IPSEC, etc), > you need to load aesni.ko' >=20 > Userspace crypto that uses openssl or similar libraries is already > taking advantage of these CPU instructions if they are available, by > excluding this feature from GENERIC we are just causing the "out of the > box" experience to by very very slow for crypto. >=20 > For example, writing 1MB blocks to a GELI encrypted swap-backed md(4) > device: >=20 > with 8 jobs on a 10 core Intel Xeon CPU E5-2630 v4 @ 2.20GHz >=20 > fio --filename=3D/dev/md0.eli --device=3D1 --name=3Dgeli --rw=3Dwrite --b= s=3D1m > --numjobs=3D8 --iodepth=3D16 --end_fsync=3D1 --ioengine=3Dpvsync > --group_reporting --fallocate=3Dnone --runtime=3D60 --time_based >=20 >=20 > stock: > write: IOPS=3D530, BW=3D530MiB/s (556MB/s) (31.1GiB/60012msec) >=20 > with aesni.ko loaded: > write: IOPS=3D2824, BW=3D2825MiB/s (2962MB/s) (166GiB/60002msec) >=20 >=20 > Does anyone have a compelling reason to deny our users the 5x speedup? Note: HardenedBSD has had AESNI enabled on amd64 for nearly six years. Not a single complaint. For reference, HardenedBSD commit: a5aabd1c8dcc2a5097de56c54ec2a1c8d9352896 Thanks, --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Sha= wn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc --ji2eli3lbepfjcm2 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAl/uL2MACgkQ/y5nonf4 4fqIYhAAkqe9elnalcTGC+NO9jn6QHR+jITE5Vc33JE1xyDts9YcJVJCEOC5wvwK 4iKxzlkdMYesjZhubslOhtov2lzCWW/h7Nks9VlBsa9LVcqea1EFf4qmUiPoDIto OlhH8Tr6mvohdlX/TtB2G0YGQ1euZdZM3VlnEDo7GGJJcKVEE9XTo0eXzi9Wq/yQ 2DJLgLHuS1hkENQfebFB+OSOnbVuP/wQEjSXwndHgGy20gzXOqWnfXLy7tMl4EhX H840LF6WX7Hyk+l81DWZP20a4IUhm2C6nFYCYrskmu4Hm51zKTM9GvghJl1QHGsH v/0UQX6+NlRI5ebvUlZELvX0K+qMxTQPBCvVX5xGGqcWLrvx7Q+6t+2uQn1DKD6Z CrSSgCR3AFBK5dJjkvD08XNW+TjVHphiqNoz3Tz6J6UWCv7hSlYdvx2vdv8KmllJ NqBfgD9TEQ+epqWUnqu5jn13h7Vtie82XH12jejKpzQovBLQEKRSt/hvJuhwOQdO sui3oulUCcl43BxUnkBVXMc2BIRbL08a0wFw7Wrm/W6dJ9rbfbiQVKGvs5IEkCLz AVoVG30b8IkOLryMT0c09bCmhW7gzbIc9S+dwk38aFHFcGsl5vRyp37SxOkGxecu 67mz5uFv9pXQXNPzztKFslXTYYbQHoYn6PYD7LMU5os+Qp66VKk= =1VhA -----END PGP SIGNATURE----- --ji2eli3lbepfjcm2-- From owner-freebsd-current@freebsd.org Thu Dec 31 20:15:14 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 E67094CE560 for ; Thu, 31 Dec 2020 20:15:14 +0000 (UTC) (envelope-from franco@lastsummer.de) Received: from host64.shmhost.net (host64.shmhost.net [IPv6:2a01:4f8:a0:51d3::107:1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4D6KC65fQwz3nGQ; Thu, 31 Dec 2020 20:15:14 +0000 (UTC) (envelope-from franco@lastsummer.de) Received: from p200300cd872642fc7c888ba79e3874ef.dip0.t-ipconnect.de (p200300cd872642fc7c888ba79e3874ef.dip0.t-ipconnect.de [IPv6:2003:cd:8726:42fc:7c88:8ba7:9e38:74ef]) by host64.shmhost.net (Postfix) with ESMTPSA id 4D6KBy4BqczNsgY; Thu, 31 Dec 2020 21:15:06 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\)) Subject: Re: Enabling AESNI by default From: Franco Fichtner In-Reply-To: <20201231200702.22gvepvlzfwncalz@mutt-hbsd> Date: Thu, 31 Dec 2020 21:15:02 +0100 Cc: Allan Jude , FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: <7DF6338B-9DDF-4F3C-B217-DADD72D16898@lastsummer.de> References: <5d56280e-a8dd-b28d-7039-f8fe0bc0cd6f@freebsd.org> <20201231200702.22gvepvlzfwncalz@mutt-hbsd> To: Shawn Webb X-Mailer: Apple Mail (2.3608.120.23.2.4) X-Virus-Scanned: clamav-milter 0.102.4 at host64.shmhost.net X-Virus-Status: Clean X-Rspamd-Queue-Id: 4D6KC65fQwz3nGQ X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 31 Dec 2020 20:15:15 -0000 h= ttps://cgit.freebsd.org/src/commit/sys/crypto/aesni?h=3Dstable/12&id=3D95b= 37a4ed741fd116809d0f2cb295c4e9977f5b6 may have subtly broken a number of IPsec installations by stalling = active connections after certain amounts of traffic transferred. We're still trying to confirm, but it looks like this had an overall impact on 12.0 and 12.1 except that only one person in OPNsense traced it back to = aesni.ko to our knowledge to effective work around an apparent issue there. If that is not the actual fix, the problem still exists in 12.2 and = onward ;) https://github.com/opnsense/core/issues/4415 To answer the question: I guess so, yes, enable for all to have proper = errata and increased "test" coverage... Cheers, Franco > On 31. Dec 2020, at 9:07 PM, Shawn Webb = wrote: >=20 > On Thu, Dec 31, 2020 at 02:51:06PM -0500, Allan Jude wrote: >> We've had the AESNI module for quite a few years now, and it has not >> caused any problems. >>=20 >> I am wondering if there are any objections to including it in = GENERIC, >> so that users get the benefit without having to have the "tribal >> knowledge" that 'to accelerate kernel crypto (GELI, ZFS, IPSEC, etc), >> you need to load aesni.ko' >>=20 >> Userspace crypto that uses openssl or similar libraries is already >> taking advantage of these CPU instructions if they are available, by >> excluding this feature from GENERIC we are just causing the "out of = the >> box" experience to by very very slow for crypto. >>=20 >> For example, writing 1MB blocks to a GELI encrypted swap-backed md(4) >> device: >>=20 >> with 8 jobs on a 10 core Intel Xeon CPU E5-2630 v4 @ 2.20GHz >>=20 >> fio --filename=3D/dev/md0.eli --device=3D1 --name=3Dgeli --rw=3Dwrite = --bs=3D1m >> --numjobs=3D8 --iodepth=3D16 --end_fsync=3D1 --ioengine=3Dpvsync >> --group_reporting --fallocate=3Dnone --runtime=3D60 --time_based >>=20 >>=20 >> stock: >> write: IOPS=3D530, BW=3D530MiB/s (556MB/s) (31.1GiB/60012msec) >>=20 >> with aesni.ko loaded: >> write: IOPS=3D2824, BW=3D2825MiB/s (2962MB/s) (166GiB/60002msec) >>=20 >>=20 >> Does anyone have a compelling reason to deny our users the 5x = speedup? >=20 > Note: HardenedBSD has had AESNI enabled on amd64 for nearly six years. > Not a single complaint. >=20 > For reference, HardenedBSD commit: > a5aabd1c8dcc2a5097de56c54ec2a1c8d9352896 >=20 > Thanks, >=20 > --=20 > Shawn Webb > Cofounder / Security Engineer > HardenedBSD >=20 > GPG Key ID: 0xFF2E67A277F8E1FA > GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 = 0FB2 > = https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Sh= awn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc From owner-freebsd-current@freebsd.org Thu Dec 31 20:35:56 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 606E14CEDC6 for ; Thu, 31 Dec 2020 20:35:56 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4D6Kfz24d9z3pln; Thu, 31 Dec 2020 20:35:54 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Date: Thu, 31 Dec 2020 21:35:53 +0100 (CET) From: Ronald Klop To: FreeBSD Current , Allan Jude Message-ID: <750559933.8900.1609446953164@localhost> In-Reply-To: <5d56280e-a8dd-b28d-7039-f8fe0bc0cd6f@freebsd.org> Subject: Re: Enabling AESNI by default MIME-Version: 1.0 X-Mailer: Realworks (539.21.0bd30ccdda9) Importance: Normal X-Priority: 3 (Normal) X-Rspamd-Queue-Id: 4D6Kfz24d9z3pln X-Spamd-Bar: - X-Spamd-Result: default: False [-1.50 / 15.00]; ARC_NA(0.00)[]; RWL_MAILSPIKE_VERYGOOD(0.00)[194.109.157.24:from]; R_DKIM_ALLOW(-0.20)[klop.ws:s=rw2]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[klop.ws:+]; RCPT_COUNT_TWO(0.00)[2]; HAS_X_PRIO_THREE(0.00)[3]; RCVD_IN_DNSWL_NONE(0.00)[194.109.157.24:from]; DMARC_POLICY_ALLOW(-0.50)[klop.ws,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL]; MAILMAN_DEST(0.00)[freebsd-current] Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 31 Dec 2020 20:35:56 -0000 Yes! Took me until last month to notice that I needed to load aesni in loader.conf instead of rc.conf because swap geli is configured before kld_list. Years of optimization thrown away. Regards, Ronald. Van: Allan Jude Datum: 31 december 2020 20:51 Aan: FreeBSD Current Onderwerp: Enabling AESNI by default > > > We've had the AESNI module for quite a few years now, and it has not > caused any problems. > > I am wondering if there are any objections to including it in GENERIC, > so that users get the benefit without having to have the "tribal > knowledge" that 'to accelerate kernel crypto (GELI, ZFS, IPSEC, etc), > you need to load aesni.ko' > > Userspace crypto that uses openssl or similar libraries is already > taking advantage of these CPU instructions if they are available, by > excluding this feature from GENERIC we are just causing the "out of the > box" experience to by very very slow for crypto. > > For example, writing 1MB blocks to a GELI encrypted swap-backed md(4) > device: > > with 8 jobs on a 10 core Intel Xeon CPU E5-2630 v4 @ 2.20GHz > > fio --filename=/dev/md0.eli --device=1 --name=geli --rw=write --bs=1m > --numjobs=8 --iodepth=16 --end_fsync=1 --ioengine=pvsync > --group_reporting --fallocate=none --runtime=60 --time_based > > > stock: > write: IOPS=530, BW=530MiB/s (556MB/s) (31.1GiB/60012msec) > > with aesni.ko loaded: > write: IOPS=2824, BW=2825MiB/s (2962MB/s) (166GiB/60002msec) > > > Does anyone have a compelling reason to deny our users the 5x speedup? > > > -- > Allan Jude > _______________________________________________ > 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 Dec 31 21:58: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 5450F4D0F10 for ; Thu, 31 Dec 2020 21:58:26 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "ultimatedns.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D6MV96Ssdz3v7P; Thu, 31 Dec 2020 21:58:25 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.16.1/8.16.1) with ESMTP id 0BVLx2Ou045282; Thu, 31 Dec 2020 13:59:08 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) MIME-Version: 1.0 Date: Thu, 31 Dec 2020 13:59:02 -0800 From: Chris To: Allan Jude Cc: FreeBSD Current Subject: Re: Enabling AESNI by default In-Reply-To: <5d56280e-a8dd-b28d-7039-f8fe0bc0cd6f@freebsd.org> References: <5d56280e-a8dd-b28d-7039-f8fe0bc0cd6f@freebsd.org> User-Agent: UDNSMS/17.0 Message-ID: <048a95427c6a9c30fad8f2dd882dc70f@bsdforge.com> X-Sender: bsd-lists@bsdforge.com Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4D6MV96Ssdz3v7P X-Spamd-Bar: / X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 31 Dec 2020 21:58:26 -0000 On 2020-12-31 11:51, Allan Jude wrote: > We've had the AESNI module for quite a few years now, and it has not > caused any problems. > > I am wondering if there are any objections to including it in GENERIC, > so that users get the benefit without having to have the "tribal > knowledge" that 'to accelerate kernel crypto (GELI, ZFS, IPSEC, etc), > you need to load aesni.ko' > > Userspace crypto that uses openssl or similar libraries is already > taking advantage of these CPU instructions if they are available, by > excluding this feature from GENERIC we are just causing the "out of the > box" experience to by very very slow for crypto. > > For example, writing 1MB blocks to a GELI encrypted swap-backed md(4) > device: > > with 8 jobs on a 10 core Intel Xeon CPU E5-2630 v4 @ 2.20GHz > > fio --filename=/dev/md0.eli --device=1 --name=geli --rw=write --bs=1m > --numjobs=8 --iodepth=16 --end_fsync=1 --ioengine=pvsync > --group_reporting --fallocate=none --runtime=60 --time_based > > > stock: > write: IOPS=530, BW=530MiB/s (556MB/s) (31.1GiB/60012msec) > > with aesni.ko loaded: > write: IOPS=2824, BW=2825MiB/s (2962MB/s) (166GiB/60002msec) > > > Does anyone have a compelling reason to deny our users the 5x speedup? FWIW I'd just like to suggest that I'm a +1 for adding it to GENERIC. Thanks for suggesting this, and have a Happy New Year! --Chris From owner-freebsd-current@freebsd.org Thu Dec 31 22:09:21 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 7238C4D13B2 for ; Thu, 31 Dec 2020 22:09:21 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4D6Mkm2vLsz3vgY; Thu, 31 Dec 2020 22:09:19 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 0BVM9H2x088052; Thu, 31 Dec 2020 14:09:17 -0800 (PST) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 0BVM9HHk088051; Thu, 31 Dec 2020 14:09:17 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202012312209.0BVM9HHk088051@gndrsh.dnsmgr.net> Subject: Re: Enabling AESNI by default In-Reply-To: <5d56280e-a8dd-b28d-7039-f8fe0bc0cd6f@freebsd.org> To: Allan Jude Date: Thu, 31 Dec 2020 14:09:17 -0800 (PST) CC: FreeBSD Current X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 4D6Mkm2vLsz3vgY X-Spamd-Bar: + X-Spamd-Result: default: False [1.86 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[69.59.192.140:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[dnsmgr.net]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; NEURAL_SPAM_SHORT(0.96)[0.958]; SPAMHAUS_ZRD(0.00)[69.59.192.140:from:127.0.2.255]; TO_DN_ALL(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, 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.34 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, 31 Dec 2020 22:09:21 -0000 > We've had the AESNI module for quite a few years now, and it has not > caused any problems. > > I am wondering if there are any objections to including it in GENERIC, > so that users get the benefit without having to have the "tribal > knowledge" that 'to accelerate kernel crypto (GELI, ZFS, IPSEC, etc), > you need to load aesni.ko' > > Userspace crypto that uses openssl or similar libraries is already > taking advantage of these CPU instructions if they are available, by > excluding this feature from GENERIC we are just causing the "out of the > box" experience to by very very slow for crypto. > > For example, writing 1MB blocks to a GELI encrypted swap-backed md(4) > device: > > with 8 jobs on a 10 core Intel Xeon CPU E5-2630 v4 @ 2.20GHz > > fio --filename=/dev/md0.eli --device=1 --name=geli --rw=write --bs=1m > --numjobs=8 --iodepth=16 --end_fsync=1 --ioengine=pvsync > --group_reporting --fallocate=none --runtime=60 --time_based > > > stock: > write: IOPS=530, BW=530MiB/s (556MB/s) (31.1GiB/60012msec) > > with aesni.ko loaded: > write: IOPS=2824, BW=2825MiB/s (2962MB/s) (166GiB/60002msec) > > > Does anyone have a compelling reason to deny our users the 5x speedup? Its for ever dead code on a large number of machines that do not have the hardware for it. I know that is a decreasing set, but imho it would be better to somehow ONLY load the module if you had CPU support for it. The down side is that detection would probably have to be in the laoder as this code can be used very early on. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-current@freebsd.org Thu Dec 31 22:15:38 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 A86D04D19F5 for ; Thu, 31 Dec 2020 22:15:38 +0000 (UTC) (envelope-from rwmaillists@googlemail.com) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D6Mt14flkz3w5Y for ; Thu, 31 Dec 2020 22:15:37 +0000 (UTC) (envelope-from rwmaillists@googlemail.com) Received: by mail-wr1-x431.google.com with SMTP id d26so20957884wrb.12 for ; Thu, 31 Dec 2020 14:15:37 -0800 (PST) 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:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=XQk0lOjIj1enK/EahccP7ECV36ZghI+8znKIqyfl9k4=; b=MQRhxYoLtfBX26EXSeOKQHEoHk9J4qZztjX/rqFXwCKuQw6X5Q4AW8HLebhnXKy5qd 7czAKxHcLRNpLyZv9rCe2wXm9q2SDo/cV3zgZYiD3w7hI4ovnpDn/uHPaVoQM0ysEIUk 5aMxqvW6TgZQbtcdlhsSvbGcTIECAIt4GA6Emmn4o4UuBBWAaWbx0bxqH+BgLkfwoffH o6SSJuKWQcxzaTgNoIoRutg5dHvZOSe0Z83txXZ5ySLWITWD4vkNKBXSfNGDMnpVn50b aRBdH2kZSJ3pGqoFX+8Tq2/a/KFkEytWnXltWu5sgh5Qg4YfXxaSjaPYYmpeAw7Y6qW6 4dAQ== X-Gm-Message-State: AOAM530APwMQpw4aVTOa3/x0epjQLRRMRvzR77qySwlmErODzUnOjdf0 P43QoIakuxLqYc0PNaah21fIlM9+hPX9Cw== X-Google-Smtp-Source: ABdhPJwC2NnHvZqN1SGaMlZQ7g4kcNbWttKkHca7JIKyqhXjmrmlER9v1p7bbt/5sg9dBANUuCL19Q== X-Received: by 2002:a5d:4f10:: with SMTP id c16mr65006960wru.398.1609452935450; Thu, 31 Dec 2020 14:15:35 -0800 (PST) Received: from gumby.homeunix.com ([2.220.21.184]) by smtp.gmail.com with ESMTPSA id o74sm16305405wme.36.2020.12.31.14.15.33 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 31 Dec 2020 14:15:34 -0800 (PST) Date: Thu, 31 Dec 2020 22:15:30 +0000 From: RW To: freebsd-current@freebsd.org Subject: Re: HEADS UP: FreeBSD src repo transitioning to git this weekend Message-ID: <20201231221530.4f709bb6@gumby.homeunix.com> In-Reply-To: <20201231193908.GC31099@funkthat.com> References: <5fdc0b90.1c69fb81.866eb.8c29SMTPIN_ADDED_MISSING@mx.google.com> <20201218175241.GA72552@spindle.one-eyed-alien.net> <20201218182820.1P0tK%steffen@sdaoden.eu> <20201223023242.GG31099@funkthat.com> <20201223162417.v7Ce6%steffen@sdaoden.eu> <20201229011939.GU31099@funkthat.com> <20201229210454.Lh4y_%steffen@sdaoden.eu> <20201230004620.GB31099@funkthat.com> <20201231193908.GC31099@funkthat.com> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.32; amd64-portbld-freebsd12.1) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4D6Mt14flkz3w5Y X-Spamd-Bar: - X-Spamd-Result: default: False [-1.90 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[googlemail.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)[googlemail.com:+]; DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine]; NEURAL_HAM_SHORT(-0.90)[-0.903]; RECEIVED_SPAMHAUS_PBL(0.00)[2.220.21.184:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[googlemail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a00:1450:4864:20::431:from]; DWL_DNSWL_NONE(0.00)[googlemail.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[googlemail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[2a00:1450:4864:20::431:from:127.0.2.255]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::431:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 31 Dec 2020 22:15:38 -0000 On Thu, 31 Dec 2020 11:39:08 -0800 John-Mark Gurney wrote: > grarpamp wrote this message on Wed, Dec 30, 2020 at 00:55 -0500: > > > signatures of the magnet links > > > > Signing torrent.asc, with stronger or even same hash as BT > > protocol, still serve purpose of authenticate torrent file back > > to a signer to the degree therein, caveat their platform security, > > caveat sha-1 inside torrent still being abuseable by third party, > > caveat etc > One of the large parts of security is that not everyone knows the > in's and out's of security, so people who don't know, will have heard > that SHA-1 is a cryptographic hash, and assume that something is > secure when using it. Is there any reason to think it's insecure? Even if a collision attack can be make to work against bittorrent, the attacker would need to have control over the contents of the legitimate torrent as well as the bogus one. It wouldn't be "abuseable by third party". From owner-freebsd-current@freebsd.org Thu Dec 31 22:20:12 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 D7A334D1C71 for ; Thu, 31 Dec 2020 22:20:12 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D6MzJ5rHVz4Qv1; Thu, 31 Dec 2020 22:20:12 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: from venus.codepro.be (venus.codepro.be [5.9.86.228]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.codepro.be", Issuer "R3" (verified OK)) (Authenticated sender: kp) by smtp.freebsd.org (Postfix) with ESMTPSA id A1F2723DD2; Thu, 31 Dec 2020 22:20:12 +0000 (UTC) (envelope-from kp@FreeBSD.org) Received: by venus.codepro.be (Postfix, authenticated sender kp) id 1B6F61156A; Thu, 31 Dec 2020 23:20:11 +0100 (CET) From: "Kristof Provost" To: "Rodney W. Grimes" Cc: "Allan Jude" , "FreeBSD Current" Subject: Re: Enabling AESNI by default Date: Thu, 31 Dec 2020 23:20:10 +0100 X-Mailer: MailMate (1.13.2r5673) Message-ID: <0D67F84B-248D-4680-8D91-2CAEDCDD7ED7@FreeBSD.org> In-Reply-To: <202012312209.0BVM9HHk088051@gndrsh.dnsmgr.net> References: <202012312209.0BVM9HHk088051@gndrsh.dnsmgr.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 31 Dec 2020 22:20:12 -0000 On 31 Dec 2020, at 23:09, Rodney W. Grimes wrote: > Its for ever dead code on a large number of machines that do not have > the hardware for it. I know that is a decreasing set, but imho it > would be better to somehow ONLY load the module if you had CPU > support for it. The down side is that detection would probably have > to be in the laoder as this code can be used very early on. > According to kldstat it uses all of 42KB of memory. 16 1 0xffffffff83313000 a290 aesni.ko That’s such a trivial amount of memory it’s not even worth mentioning. Even in tiny embedded systems (and who runs tiny embedded systems on x86?) it’s utterly insignificant. Even if it were significant, how many of the systems without the relevant hardware are ever going to run 13? Regards, Kristof From owner-freebsd-current@freebsd.org Thu Dec 31 22:24: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 7B1164D2073 for ; Thu, 31 Dec 2020 22:24:22 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ot1-f53.google.com (mail-ot1-f53.google.com [209.85.210.53]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D6N462s77z4RSR; Thu, 31 Dec 2020 22:24:22 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-ot1-f53.google.com with SMTP id a109so19006063otc.1; Thu, 31 Dec 2020 14:24:22 -0800 (PST) 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=midb6U5oXc2/A+yy8BtZWx6LHy5k3MrcHP2+r7XmIng=; b=BOjSEInuT6PN+2oLg7V7QrIN22BvaR8p06it0U6VphZ2Ma+zk7i1zsaVXEA+maGsQY XK+wf6POYbSSzL/GWUimK8m1h7JGfQq/jrrdbiOzwffaJXvBZRasIAf6XPzY7yEjoOXY WXrzCPO8hi5IK258w/hyvPLJdbz0rMDlDsV2OXsAEtO4D5qDtLOnzFuwXlAimpnEip4q OixryEFfvWcQ9oJK8ToB3wY3JqiK6gThOTjyH9J0IkTa710gxIag3e7sRtQ9xmSVUn8g tAQx73UU9hSN97jnUTu/9YdFfyjcmkok19k9xr76OnnxHEVFxamCbA2bZxKOyYwpOE7q rsvg== X-Gm-Message-State: AOAM5326ca8EnuM2N12sZWCgcdmEifrn9U8kRZvvXTEXQYJz0pQFtSUP +yWZlw7kLT3imH4mL1xIDIk0Nc4JpdQ2qDOJsRCZRYIhMZY= X-Google-Smtp-Source: ABdhPJzJ9oSG86A9ahroEbvEn27MD0SgGHdyBkRif4qp35Au2UvSoQb8soV2e1S6ZWMqybJoFkVcyNvnCbNdsMNNCMw= X-Received: by 2002:a05:6830:30a8:: with SMTP id g8mr41465504ots.291.1609453461199; Thu, 31 Dec 2020 14:24:21 -0800 (PST) MIME-Version: 1.0 References: <202012312209.0BVM9HHk088051@gndrsh.dnsmgr.net> <0D67F84B-248D-4680-8D91-2CAEDCDD7ED7@FreeBSD.org> In-Reply-To: <0D67F84B-248D-4680-8D91-2CAEDCDD7ED7@FreeBSD.org> From: Alan Somers Date: Thu, 31 Dec 2020 15:24:09 -0700 Message-ID: Subject: Re: Enabling AESNI by default To: Kristof Provost Cc: "Rodney W. Grimes" , Allan Jude , FreeBSD Current X-Rspamd-Queue-Id: 4D6N462s77z4RSR X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 31 Dec 2020 22:24:22 -0000 On Thu, Dec 31, 2020 at 3:20 PM Kristof Provost wrote: > On 31 Dec 2020, at 23:09, Rodney W. Grimes wrote: > > Its for ever dead code on a large number of machines that do not have > > the hardware for it. I know that is a decreasing set, but imho it > > would be better to somehow ONLY load the module if you had CPU > > support for it. The down side is that detection would probably have > > to be in the laoder as this code can be used very early on. > > > According to kldstat it uses all of 42KB of memory. > > 16 1 0xffffffff83313000 a290 aesni.ko > > That=E2=80=99s such a trivial amount of memory it=E2=80=99s not even wort= h > mentioning. Even in tiny embedded systems (and who runs tiny embedded > systems on x86?) it=E2=80=99s utterly insignificant. > > Even if it were significant, how many of the systems without the > relevant hardware are ever going to run 13? > > Regards, > Kristof > And tiny embedded systems are probably running custom kernels anyway, so they can remove it. I'm sold. Let's put it in GENERIC. -Alan From owner-freebsd-current@freebsd.org Thu Dec 31 22:28: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 14D4A4D25A4 for ; Thu, 31 Dec 2020 22:28:09 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D6N8S6yTVz4RhJ; Thu, 31 Dec 2020 22:28:08 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro.local (unknown [IPv6:2601:648:8681:1cb0:e936:7c25:afe9:9450]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 7719C23FF5; Thu, 31 Dec 2020 22:28:08 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Subject: Re: PCIe Root Port/Bus Not Detected in VMD To: Neel Chauhan , freebsd-current@freebsd.org References: From: John Baldwin Autocrypt: addr=jhb@FreeBSD.org; keydata= mQGiBETQ+XcRBADMFybiq69u+fJRy/0wzqTNS8jFfWaBTs5/OfcV7wWezVmf9sgwn8TW0Dk0 c9MBl0pz+H01dA2ZSGZ5fXlmFIsee1WEzqeJzpiwd/pejPgSzXB9ijbLHZ2/E0jhGBcVy5Yo /Tw5+U/+laeYKu2xb0XPvM0zMNls1ah5OnP9a6Ql6wCgupaoMySb7DXm2LHD1Z9jTsHcAQMD /1jzh2BoHriy/Q2s4KzzjVp/mQO5DSm2z14BvbQRcXU48oAosHA1u3Wrov6LfPY+0U1tG47X 1BGfnQH+rNAaH0livoSBQ0IPI/8WfIW7ub4qV6HYwWKVqkDkqwcpmGNDbz3gfaDht6nsie5Z pcuCcul4M9CW7Md6zzyvktjnbz61BADGDCopfZC4of0Z3Ka0u8Wik6UJOuqShBt1WcFS8ya1 oB4rc4tXfSHyMF63aPUBMxHR5DXeH+EO2edoSwViDMqWk1jTnYza51rbGY+pebLQOVOxAY7k do5Ordl3wklBPMVEPWoZ61SdbcjhHVwaC5zfiskcxj5wwXd2E9qYlBqRg7QeSm9obiBCYWxk d2luIDxqaGJARnJlZUJTRC5vcmc+iGAEExECACAFAkTQ+awCGwMGCwkIBwMCBBUCCAMEFgID AQIeAQIXgAAKCRBy3lIGd+N/BI6RAJ9S97fvbME+3hxzE3JUyUZ6vTewDACdE1stFuSfqMvM jomvZdYxIYyTUpC5Ag0ERND5ghAIAPwsO0B7BL+bz8sLlLoQktGxXwXQfS5cInvL17Dsgnr3 1AKa94j9EnXQyPEj7u0d+LmEe6CGEGDh1OcGFTMVrof2ZzkSy4+FkZwMKJpTiqeaShMh+Goj XlwIMDxyADYvBIg3eN5YdFKaPQpfgSqhT+7El7w+wSZZD8pPQuLAnie5iz9C8iKy4/cMSOrH YUK/tO+Nhw8Jjlw94Ik0T80iEhI2t+XBVjwdfjbq3HrJ0ehqdBwukyeJRYKmbn298KOFQVHO EVbHA4rF/37jzaMadK43FgJ0SAhPPF5l4l89z5oPu0b/+5e2inA3b8J3iGZxywjM+Csq1tqz hltEc7Q+E08AAwUIAL+15XH8bPbjNJdVyg2CMl10JNW2wWg2Q6qdljeaRqeR6zFus7EZTwtX sNzs5bP8y51PSUDJbeiy2RNCNKWFMndM22TZnk3GNG45nQd4OwYK0RZVrikalmJY5Q6m7Z16 4yrZgIXFdKj2t8F+x613/SJW1lIr9/bDp4U9tw0V1g3l2dFtD3p3ZrQ3hpoDtoK70ioIAjjH aIXIAcm3FGZFXy503DOA0KaTWwvOVdYCFLm3zWuSOmrX/GsEc7ovasOWwjPn878qVjbUKWwx Q4QkF4OhUV9zPtf9tDSAZ3x7QSwoKbCoRCZ/xbyTUPyQ1VvNy/mYrBcYlzHodsaqUDjHuW+I SQQYEQIACQUCRND5ggIbDAAKCRBy3lIGd+N/BCO8AJ9j1dWVQWxw/YdTbEyrRKOY8YZNwwCf afMAg8QvmOWnHx3wl8WslCaXaE8= Message-ID: <40b48007-5e60-cd87-0242-15239869d370@FreeBSD.org> Date: Thu, 31 Dec 2020 14:28:07 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 31 Dec 2020 22:28:09 -0000 On 12/30/20 9:45 PM, Neel Chauhan wrote: > For reference, I am attaching the `pciconf -lv` and `acpidump -dt` > dumps. Hmm, the acpidump doesn't have the -d contents, only the -t, and PCI bridges are generally enumerated in the the -d part. These PCI bridges aren't enumerated in ACPI though, so that probably doesn't matter. The dinfo getting 0xffff means that somehow the way the PCI config access is being handled for the child devices in vmd.c is wrong for this bridge. You might have to spelunk in the Linux driver to see if the logic in vmd_read_config() and vmd_write_config() is correct. -- -- John Baldwin From owner-freebsd-current@freebsd.org Thu Dec 31 22:40: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 C5B8D4D2455; Thu, 31 Dec 2020 22:40:29 +0000 (UTC) (envelope-from ctuffli@gmail.com) Received: from mail-yb1-xb36.google.com (mail-yb1-xb36.google.com [IPv6:2607:f8b0:4864:20::b36]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D6NQj15thz4Sct; Thu, 31 Dec 2020 22:40:28 +0000 (UTC) (envelope-from ctuffli@gmail.com) Received: by mail-yb1-xb36.google.com with SMTP id b64so18406989ybg.7; Thu, 31 Dec 2020 14:40:28 -0800 (PST) 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=dENlIFGyCC204O2QpCq/NI6BSlYfb37z4S24W0PmJFY=; b=tP6Fvpj4eHyaTmyBYI4hx4uRAo6IxLbGZxl+h+4BDgYOZA9OlLxXgtTs7iFOp9IqkE e1f/sldKfkIGkAqIyUN8LsOLdF5fNe5MI4rgSynw2QRJPjDZ4LvNbpX1ypiPcvwSYveP RoXbhloDXbzLegUy04vFdlI6d/2iO1/q3/EeytiXtZTRirlndP6ErqRApg7dYe7wi/Oq njb+FH6SU6SlAdFc2Oi2GXSHsVfaeD+G0u9bi9L4oOI2K5r1paWhYDioHYGe+3Yz6Pyy 5QOYMFzlmirxR2PQXXpNOEyIZPbSNAK7gf7LRnE7DsxFhZkzs8K3K388yMJGne2hUtIK SOIw== X-Gm-Message-State: AOAM531GkJ9sSyeRsZF/sH0FZLoEQRnCsT/n8rcA6hEU9EldBSpOItJI gXe/KaL3H4pc9XEXl5w8e3wtTraWUNd15U/xw6I= X-Google-Smtp-Source: ABdhPJzaa+hKIL7m7iWyj3vymBykV6oLfpyJq2iqTpz7ZPWfwEhcvs9Fs1w/tOQjGjSG8OC0q8+NqvCfukwa515Z0Gs= X-Received: by 2002:a25:9906:: with SMTP id z6mr55855559ybn.238.1609454428055; Thu, 31 Dec 2020 14:40:28 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Chuck Tuffli Date: Thu, 31 Dec 2020 14:40:17 -0800 Message-ID: Subject: Re: Intel TigerLake NVMe vmd: Adding Support & Debugging a Patch To: Neel Chauhan Cc: freebsd-hackers@freebsd.org, FreeBSD-Current Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4D6NQj15thz4Sct X-Spamd-Bar: / X-Spamd-Result: default: False [0.00 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_SHORT(1.00)[1.000]; RBL_DBL_DONT_QUERY_IPS(0.00)[2607:f8b0:4864:20::b36:from]; TO_DN_SOME(0.00)[]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; SPAMHAUS_ZRD(0.00)[2607:f8b0:4864:20::b36:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::b36:from]; NEURAL_HAM_LONG(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-hackers,freebsd-current]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 31 Dec 2020 22:40:29 -0000 On Wed, Dec 30, 2020 at 4:38 PM Neel Chauhan wrote: > > Hi Chuck, > > On 2020-12-30 10:04, Chuck Tuffli wrote: > > What is the output from > > # pciconf -rb pci0:0:14:0 0x40:0x48 > > The output is: > > 01 00 00 00 01 2e 68 02 00 Perfect. The Linux driver says the 8086:9a0b device you have "... may provide root port configuration information which limits bus numbering" which causes the code to read the VM Capability register (0x40) and the VM Configuration register (0x44). Here, VMCAP = 0x0001 where bit 0 set appears to mean the config register has starting bus number information. VMCFG = 0x2e01 where bits 5:4 give the coded start number of bus 224 or 0xe0 which matches the PCI bridge shown in the lspci output (i.e. 10000:e0:06.0). I wonder if mirroring the logic in [1] and setting bus->rman.rm_start = 224; in vmd_attach() might help. > I was also able to stop kernel panics by adding: > > rman_fini(&sc->vmd_bus.rman); > > In the fail: statement in vmd_attach(). > > But I still cannot detect the SSD. [1] https://github.com/torvalds/linux/blob/master/drivers/pci/controller/vmd.c#L507 --chuck From owner-freebsd-current@freebsd.org Thu Dec 31 22:46: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 4F7E64D28A3 for ; Thu, 31 Dec 2020 22:46:19 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound2k.ore.mailhop.org (outbound2k.ore.mailhop.org [54.148.219.64]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4D6NYR0X8rz4T7L for ; Thu, 31 Dec 2020 22:46:18 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1609454777; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=WBFe9R/+d/3ZcQMaMsIdhbU0K6IOBl5GctTuTFyiWIoV+Dil8n0cf+gicOkfl5MyGALg99nq852F4 1dNTBlf/d1x5qjkASv6NwDRenuUzYzElkDg3tzauCHJxFOEaONc8tYTBHJqPO2/aQag5pCJF3NN/68 MbX42ke/nJPXgAT9vFXLFT9CXAJ11U9cVIWqpaJYLCdWuU2lcDfPuUSu4UXk+aphV28IhNP2W73WnS iuP3/GjfViOxA2F5+utIkMON6FxAA9HVn/gqETpMFzPoc2qTBPlw23a+XgHssfs2saS6D+Y6LLlZnQ r37Z0jw5HBdcszwIf5R++nMfUKyxa0w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:dkim-signature:from; bh=2zzJnPJiu8eG9XYoNgNglD2f+EscDdXk9MvCnv/0NHA=; b=dq6FF37cSRZUdUhYZkoDWLZlgiQS7dJR9p+TSVYHr1W4sxFDLN7P6p0GRX7lAtUzDQBoj6WmLLN8d BxHtl8FBx6KpPH8BY2A/JrFBDKHFN53vOPmMh8Qj+eSZ7IVBBj0acY75YGPknODAcYPxdZvjlzZxuX JAUEBcqg3jZdIMAb5wUeyirIZWlhJLYKIByrJuOT40oOFexem1uLAKfHcdsFAg408s/8fEKl4PpN4F xwEsqudUuokj+nyfeDFtALQWdrcyujzqPLnvr/MIv8a+vnjzXX/nUSzriF6v9BfXXpumxrAqy1h06d ty6I6e9F4V1O1QEdYJY6wVLwR/TEvJg== ARC-Authentication-Results: i=1; outbound4.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; X-MHO-RoutePath: aGlwcGll X-MHO-User: fced9c4a-4bb9-11eb-9e76-df46ed8f892f X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (c-67-177-211-60.hsd1.co.comcast.net [67.177.211.60]) by outbound4.ore.mailhop.org (Halon) with ESMTPSA id fced9c4a-4bb9-11eb-9e76-df46ed8f892f; Thu, 31 Dec 2020 22:46:16 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id 0BVMkEi0012466; Thu, 31 Dec 2020 15:46:14 -0700 (MST) (envelope-from ian@freebsd.org) Message-ID: <93dd4cadbcfbe8883a72144772d713a24124c584.camel@freebsd.org> Subject: Re: Enabling AESNI by default From: Ian Lepore To: "Rodney W. Grimes" , Allan Jude Cc: FreeBSD Current Date: Thu, 31 Dec 2020 15:46:14 -0700 In-Reply-To: <202012312209.0BVM9HHk088051@gndrsh.dnsmgr.net> References: <202012312209.0BVM9HHk088051@gndrsh.dnsmgr.net> Content-Type: text/plain; charset="ASCII" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4D6NYR0X8rz4T7L X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 31 Dec 2020 22:46:19 -0000 On Thu, 2020-12-31 at 14:09 -0800, Rodney W. Grimes wrote: > > We've had the AESNI module for quite a few years now, and it has > > not > > caused any problems. > > > > I am wondering if there are any objections to including it in > > GENERIC, > > so that users get the benefit without having to have the "tribal > > knowledge" that 'to accelerate kernel crypto (GELI, ZFS, IPSEC, > > etc), > > you need to load aesni.ko' > > > > Userspace crypto that uses openssl or similar libraries is already > > taking advantage of these CPU instructions if they are available, > > by > > excluding this feature from GENERIC we are just causing the "out of > > the > > box" experience to by very very slow for crypto. > > > > For example, writing 1MB blocks to a GELI encrypted swap-backed > > md(4) > > device: > > > > with 8 jobs on a 10 core Intel Xeon CPU E5-2630 v4 @ 2.20GHz > > > > fio --filename=/dev/md0.eli --device=1 --name=geli --rw=write -- > > bs=1m > > --numjobs=8 --iodepth=16 --end_fsync=1 --ioengine=pvsync > > --group_reporting --fallocate=none --runtime=60 --time_based > > > > > > stock: > > write: IOPS=530, BW=530MiB/s (556MB/s) (31.1GiB/60012msec) > > > > with aesni.ko loaded: > > write: IOPS=2824, BW=2825MiB/s (2962MB/s) (166GiB/60002msec) > > > > > > Does anyone have a compelling reason to deny our users the 5x > > speedup? > > Its for ever dead code on a large number of machines that do not have > the hardware for it. I know that is a decreasing set, but imho it > would be better to somehow ONLY load the module if you had CPU > support for it. The down side is that detection would probably have > to be in the laoder as this code can be used very early on. > Not nearly so much as the code to support the PC/AT RTC and i8254 hardware as kernel eventtimers is dead code, probably today on virtually every x86 machine that runs freebsd. In other words, if you want to start worrying about mostly-unused code, aesni is not the place to start. -- Ian From owner-freebsd-current@freebsd.org Thu Dec 31 22:47: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 A1AFD4D2BDC for ; Thu, 31 Dec 2020 22:47:22 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from mail.netplex.net (mail.netplex.net [204.213.176.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.netplex.net", Issuer "RapidSSL RSA CA 2018" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D6NZf1Vrsz4T8V; Thu, 31 Dec 2020 22:47:21 +0000 (UTC) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.netplex.net (8.15.1/8.15.1/NETPLEX) with ESMTP id 0BVMlGoQ035036; Thu, 31 Dec 2020 17:47:21 -0500 X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.netplex.net) X-Greylist: Message whitelisted by DRAC access database, not delayed by milter-greylist-4.4.3 (mail.netplex.net [204.213.176.9]); Thu, 31 Dec 2020 17:47:21 -0500 (EST) Date: Thu, 31 Dec 2020 17:47:16 -0500 (EST) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net Reply-To: Daniel Eischen To: freebsd-current@freebsd.org cc: pfg@freebsd.org Subject: Bug in r361898 (was Re: poudriere: services_mkdb recompile with larger PROTOMAX) In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Rspamd-Queue-Id: 4D6NZf1Vrsz4T8V X-Spamd-Bar: / X-Spamd-Result: default: False [0.00 / 15.00]; local_wl_from(0.00)[freebsd.org]; ASN(0.00)[asn:6062, ipnet:204.213.176.0/20, country:US] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 31 Dec 2020 22:47:22 -0000 On Thu, 31 Dec 2020, Daniel Eischen wrote: > I see this message in src/UPDATING: > > 20201216: > The services database has been updated to cover more of the basic > services expected in a modern system. The database is big enough > that it will cause issues in mergemaster in Releases previous to > 12.2 and 11.3, or in very old current systems from before r358154. > > I'm trying to update a poudriere jail from a freshly built -current > system (r368820): > > FreeBSD vega.my.domain 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r368820 > Wed Dec 30 15:55:06 EST 2020 > > I've tried running this command twice: > > export MAKEOBJDIRPREFIX=/opt/FreeBSD/obj/head.obj > poudriere jail -u -j 13amd64 > > [ /opt/FreeBSD/obj/head.obj is my freshly built (r368820) obj tree is ] > > services_mkdb was updated in the jail on the first pass: > > # ls -l /usr/local/poudriere/jails/13amd64/usr/sbin/services_mkdb > -r-xr-xr-x 1 root wheel 15288 Dec 31 13:02 > /usr/local/poudriere/jails/13amd64/usr/sbin/services_mkdb > > But as on the first pass of 'poudriere jail -u -j 13amd64`, I still get > the following error: > > ... > > --- _CONFSINS_services --- > install -N /opt/FreeBSD/svn/head/etc -C -o root -g wheel -m 644 > /opt/FreeBSD/svn/head/usr.sbin/services_mkdb/services > /usr/local/poudriere/jails/13amd64/etc/services > --- installconfig_subdir_usr.bin --- > --- installconfig_subdir_usr.bin/nice --- > ===> usr.bin/nice (installconfig) > --- installconfig_subdir_usr.sbin --- > --- afterinstallconfig --- > --- installconfig_subdir_lib --- > --- installconfig_subdir_lib/ncurses --- > --- installconfig_subdir_lib/ncurses/ncurses --- > ===> lib/ncurses/ncurses (installconfig) > --- installconfig_subdir_usr.sbin --- > services_mkdb -l -q -o /usr/local/poudriere/jails/13amd64/var/db/services.db > /usr/local/poudriere/jails/13amd64/etc/services > --- installconfig_subdir_usr.bin --- > --- installconfig_subdir_usr.bin/nl --- > ===> usr.bin/nl (installconfig) > --- installconfig_subdir_usr.sbin --- > services_mkdb: Ran out of protocols adding `divert'; recompile with larger > PROTOMAX > > What's the work-around for this? services_mkdb seems to have been > updated on the first pass off 'poudiere jail -u ...', but still fails > on the second pass. A typo (tdp was used instead of tcp) in the services file seems to have been introduced in r361898. This is the patch that fixes the problem for me. Index: usr.sbin/services_mkdb/services =================================================================== --- usr.sbin/services_mkdb/services (revision 368820) +++ usr.sbin/services_mkdb/services (working copy) @@ -1788,7 +1788,7 @@ iscsi-target 3260/udp # iSCSI port mysql 3306/tcp #MySQL mysql 3306/udp #MySQL -ms-wbt-server 3389/tdp rdp #MS WBT Server +ms-wbt-server 3389/tcp rdp #MS WBT Server ms-wbt-server 3389/udp #MS WBT Server efi-lm 3392/tcp #EFI License Management efi-lm 3392/udp #EFI License Management -- DE From owner-freebsd-current@freebsd.org Thu Dec 31 22:51: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 B1AE14D3496 for ; Thu, 31 Dec 2020 22:51:50 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D6Ngp4KJwz4TPQ; Thu, 31 Dec 2020 22:51:50 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro.local (unknown [IPv6:2601:648:8681:1cb0:6d91:ae61:b3ec:ca03]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 0DA8123B5A; Thu, 31 Dec 2020 22:51:49 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Subject: Re: Enabling AESNI by default To: Franco Fichtner , Shawn Webb Cc: Allan Jude , FreeBSD Current References: <5d56280e-a8dd-b28d-7039-f8fe0bc0cd6f@freebsd.org> <20201231200702.22gvepvlzfwncalz@mutt-hbsd> <7DF6338B-9DDF-4F3C-B217-DADD72D16898@lastsummer.de> From: John Baldwin Autocrypt: addr=jhb@FreeBSD.org; keydata= mQGiBETQ+XcRBADMFybiq69u+fJRy/0wzqTNS8jFfWaBTs5/OfcV7wWezVmf9sgwn8TW0Dk0 c9MBl0pz+H01dA2ZSGZ5fXlmFIsee1WEzqeJzpiwd/pejPgSzXB9ijbLHZ2/E0jhGBcVy5Yo /Tw5+U/+laeYKu2xb0XPvM0zMNls1ah5OnP9a6Ql6wCgupaoMySb7DXm2LHD1Z9jTsHcAQMD /1jzh2BoHriy/Q2s4KzzjVp/mQO5DSm2z14BvbQRcXU48oAosHA1u3Wrov6LfPY+0U1tG47X 1BGfnQH+rNAaH0livoSBQ0IPI/8WfIW7ub4qV6HYwWKVqkDkqwcpmGNDbz3gfaDht6nsie5Z pcuCcul4M9CW7Md6zzyvktjnbz61BADGDCopfZC4of0Z3Ka0u8Wik6UJOuqShBt1WcFS8ya1 oB4rc4tXfSHyMF63aPUBMxHR5DXeH+EO2edoSwViDMqWk1jTnYza51rbGY+pebLQOVOxAY7k do5Ordl3wklBPMVEPWoZ61SdbcjhHVwaC5zfiskcxj5wwXd2E9qYlBqRg7QeSm9obiBCYWxk d2luIDxqaGJARnJlZUJTRC5vcmc+iGAEExECACAFAkTQ+awCGwMGCwkIBwMCBBUCCAMEFgID AQIeAQIXgAAKCRBy3lIGd+N/BI6RAJ9S97fvbME+3hxzE3JUyUZ6vTewDACdE1stFuSfqMvM jomvZdYxIYyTUpC5Ag0ERND5ghAIAPwsO0B7BL+bz8sLlLoQktGxXwXQfS5cInvL17Dsgnr3 1AKa94j9EnXQyPEj7u0d+LmEe6CGEGDh1OcGFTMVrof2ZzkSy4+FkZwMKJpTiqeaShMh+Goj XlwIMDxyADYvBIg3eN5YdFKaPQpfgSqhT+7El7w+wSZZD8pPQuLAnie5iz9C8iKy4/cMSOrH YUK/tO+Nhw8Jjlw94Ik0T80iEhI2t+XBVjwdfjbq3HrJ0ehqdBwukyeJRYKmbn298KOFQVHO EVbHA4rF/37jzaMadK43FgJ0SAhPPF5l4l89z5oPu0b/+5e2inA3b8J3iGZxywjM+Csq1tqz hltEc7Q+E08AAwUIAL+15XH8bPbjNJdVyg2CMl10JNW2wWg2Q6qdljeaRqeR6zFus7EZTwtX sNzs5bP8y51PSUDJbeiy2RNCNKWFMndM22TZnk3GNG45nQd4OwYK0RZVrikalmJY5Q6m7Z16 4yrZgIXFdKj2t8F+x613/SJW1lIr9/bDp4U9tw0V1g3l2dFtD3p3ZrQ3hpoDtoK70ioIAjjH aIXIAcm3FGZFXy503DOA0KaTWwvOVdYCFLm3zWuSOmrX/GsEc7ovasOWwjPn878qVjbUKWwx Q4QkF4OhUV9zPtf9tDSAZ3x7QSwoKbCoRCZ/xbyTUPyQ1VvNy/mYrBcYlzHodsaqUDjHuW+I SQQYEQIACQUCRND5ggIbDAAKCRBy3lIGd+N/BCO8AJ9j1dWVQWxw/YdTbEyrRKOY8YZNwwCf afMAg8QvmOWnHx3wl8WslCaXaE8= Message-ID: <919661a7-cfd6-c106-244f-16853e34b059@FreeBSD.org> Date: Thu, 31 Dec 2020 14:51:48 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: <7DF6338B-9DDF-4F3C-B217-DADD72D16898@lastsummer.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 31 Dec 2020 22:51:50 -0000 On 12/31/20 12:15 PM, Franco Fichtner wrote: > https://cgit.freebsd.org/src/commit/sys/crypto/aesni?h=stable/12&id=95b37a4ed741fd116809d0f2cb295c4e9977f5b6 > > may have subtly broken a number of IPsec installations by stalling active > connections after certain amounts of traffic transferred. We're still > trying to confirm, but it looks like this had an overall impact on 12.0 > and 12.1 except that only one person in OPNsense traced it back to aesni.ko > to our knowledge to effective work around an apparent issue there. > > If that is not the actual fix, the problem still exists in 12.2 and onward ;) We don't support AES-CCM for IPsec, so there is 0 chance that commit has any effect on IPsec in 12. There's not much detail in the forum posts though (e.g. netstat -s output to get ipsec, esp, and ah stats). Also, at least one forum post mentioned it happened when doing an upgrade from 11.2 to 12.1 which is a larger set of changes. I know the pfsense folks had a major performance regression due to iflib with Intel e1000 devices that might manifest as this perhaps? Disabling aseni might just be throttling the connection slow enough to avoid hitting a bug in a NIC driver for example. I think netstat -s would be a better place to start to try to debug this. > https://github.com/opnsense/core/issues/4415 -- John Baldwin From owner-freebsd-current@freebsd.org Thu Dec 31 22:54: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 297864D388D; Thu, 31 Dec 2020 22:54:57 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D6NlP0Qc5z4V1m; Thu, 31 Dec 2020 22:54:57 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro.local (unknown [IPv6:2601:648:8681:1cb0:6d91:ae61:b3ec:ca03]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 707EB240AE; Thu, 31 Dec 2020 22:54:56 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Subject: Re: Intel TigerLake NVMe vmd: Adding Support & Debugging a Patch To: Chuck Tuffli , Neel Chauhan Cc: freebsd-hackers@freebsd.org, FreeBSD-Current References: From: John Baldwin Autocrypt: addr=jhb@FreeBSD.org; keydata= mQGiBETQ+XcRBADMFybiq69u+fJRy/0wzqTNS8jFfWaBTs5/OfcV7wWezVmf9sgwn8TW0Dk0 c9MBl0pz+H01dA2ZSGZ5fXlmFIsee1WEzqeJzpiwd/pejPgSzXB9ijbLHZ2/E0jhGBcVy5Yo /Tw5+U/+laeYKu2xb0XPvM0zMNls1ah5OnP9a6Ql6wCgupaoMySb7DXm2LHD1Z9jTsHcAQMD /1jzh2BoHriy/Q2s4KzzjVp/mQO5DSm2z14BvbQRcXU48oAosHA1u3Wrov6LfPY+0U1tG47X 1BGfnQH+rNAaH0livoSBQ0IPI/8WfIW7ub4qV6HYwWKVqkDkqwcpmGNDbz3gfaDht6nsie5Z pcuCcul4M9CW7Md6zzyvktjnbz61BADGDCopfZC4of0Z3Ka0u8Wik6UJOuqShBt1WcFS8ya1 oB4rc4tXfSHyMF63aPUBMxHR5DXeH+EO2edoSwViDMqWk1jTnYza51rbGY+pebLQOVOxAY7k do5Ordl3wklBPMVEPWoZ61SdbcjhHVwaC5zfiskcxj5wwXd2E9qYlBqRg7QeSm9obiBCYWxk d2luIDxqaGJARnJlZUJTRC5vcmc+iGAEExECACAFAkTQ+awCGwMGCwkIBwMCBBUCCAMEFgID AQIeAQIXgAAKCRBy3lIGd+N/BI6RAJ9S97fvbME+3hxzE3JUyUZ6vTewDACdE1stFuSfqMvM jomvZdYxIYyTUpC5Ag0ERND5ghAIAPwsO0B7BL+bz8sLlLoQktGxXwXQfS5cInvL17Dsgnr3 1AKa94j9EnXQyPEj7u0d+LmEe6CGEGDh1OcGFTMVrof2ZzkSy4+FkZwMKJpTiqeaShMh+Goj XlwIMDxyADYvBIg3eN5YdFKaPQpfgSqhT+7El7w+wSZZD8pPQuLAnie5iz9C8iKy4/cMSOrH YUK/tO+Nhw8Jjlw94Ik0T80iEhI2t+XBVjwdfjbq3HrJ0ehqdBwukyeJRYKmbn298KOFQVHO EVbHA4rF/37jzaMadK43FgJ0SAhPPF5l4l89z5oPu0b/+5e2inA3b8J3iGZxywjM+Csq1tqz hltEc7Q+E08AAwUIAL+15XH8bPbjNJdVyg2CMl10JNW2wWg2Q6qdljeaRqeR6zFus7EZTwtX sNzs5bP8y51PSUDJbeiy2RNCNKWFMndM22TZnk3GNG45nQd4OwYK0RZVrikalmJY5Q6m7Z16 4yrZgIXFdKj2t8F+x613/SJW1lIr9/bDp4U9tw0V1g3l2dFtD3p3ZrQ3hpoDtoK70ioIAjjH aIXIAcm3FGZFXy503DOA0KaTWwvOVdYCFLm3zWuSOmrX/GsEc7ovasOWwjPn878qVjbUKWwx Q4QkF4OhUV9zPtf9tDSAZ3x7QSwoKbCoRCZ/xbyTUPyQ1VvNy/mYrBcYlzHodsaqUDjHuW+I SQQYEQIACQUCRND5ggIbDAAKCRBy3lIGd+N/BCO8AJ9j1dWVQWxw/YdTbEyrRKOY8YZNwwCf afMAg8QvmOWnHx3wl8WslCaXaE8= Message-ID: Date: Thu, 31 Dec 2020 14:54:55 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 31 Dec 2020 22:54:57 -0000 On 12/31/20 2:40 PM, Chuck Tuffli wrote: > On Wed, Dec 30, 2020 at 4:38 PM Neel Chauhan wrote: >> >> Hi Chuck, >> >> On 2020-12-30 10:04, Chuck Tuffli wrote: >>> What is the output from >>> # pciconf -rb pci0:0:14:0 0x40:0x48 >> >> The output is: >> >> 01 00 00 00 01 2e 68 02 00 > > Perfect. The Linux driver says the 8086:9a0b device you have "... may > provide root port configuration information which limits bus > numbering" which causes the code to read the VM Capability register > (0x40) and the VM Configuration register (0x44). Here, VMCAP = 0x0001 > where bit 0 set appears to mean the config register has starting bus > number information. VMCFG = 0x2e01 where bits 5:4 give the coded start > number of bus 224 or 0xe0 which matches the PCI bridge shown in the > lspci output (i.e. 10000:e0:06.0). > > I wonder if mirroring the logic in [1] and setting > bus->rman.rm_start = 224; > in vmd_attach() might help. > >> I was also able to stop kernel panics by adding: >> >> rman_fini(&sc->vmd_bus.rman); >> >> In the fail: statement in vmd_attach(). >> >> But I still cannot detect the SSD. > > [1] https://github.com/torvalds/linux/blob/master/drivers/pci/controller/vmd.c#L507 You will also need to subtract that starting bus number from the bus number used to compute the offset into the PCI-express region for config register read/write as this code does: https://github.com/torvalds/linux/blob/master/drivers/pci/controller/vmd.c#L339 Also, that means the vm_bus.c can't hardcode reading from bus 0. Instead, vmd(4) might need to export an IVAR to vmd_bus(4) that is the starting bus number and vm_bus needs to use that instead of hardcoding 0. -- John Baldwin From owner-freebsd-current@freebsd.org Thu Dec 31 22:56:14 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 57A364D39C0 for ; Thu, 31 Dec 2020 22:56:14 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660068.outbound.protection.outlook.com [40.107.66.68]) (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 4D6Nmt1HfLz4VV3; Thu, 31 Dec 2020 22:56:13 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iPcAmLyKLtbiGpm42VxEyknkj97r9YPK0yMLHpUJR+lCRbgl8UTT05IgB8Zf89uDau/sLhJLg15sa9Us0REI090aZStw+uZNiSpQ9dFWC+daeuYutpxvbixzF2jSSmrXkU+PAijlveC/QgHNOxKv5GO5SWb/gEKrd2OrWehv90ZaS/GVM5hUPCalgPYxjK7PEKmYP7hdUtDVw8aIgDVvAsDny0L0LGwfLC1ielEoLvqHBRvnrVYazj+4CPkjYdT8oIwdne7JpSq/J7a7zcD2sgjjVWbmYSaNDlJUwP9hmUxksk50L3YTy1ISIODSZlBLZweh9BrqbqEY4ub4hrRo6g== 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=fV9LYHICxaZKp1X7mEPgZR+mz/Gd1S6ZfKQK4TmGG5U=; b=X8w0AvWFZCUjRFR/b/3aiTlPXpBZnSuctVvmJZt7NZGOjEs1rbjiN5xoYl6FkXbQ89qUQK+D7CIzotB8/UiYzRDnKa3pNbbTvJCtPjN5VE0On/M4ouS59UwStCa640GRIJcrh1w/ytl0Dw+WgJl2lkgULnEiLnWAjY/z6mjXyp4qBrQERxBU7XasC9/5D55Xd75dcsCQpXXI5dOeY4tLsmn99LkAaR1HhdqOQ621qvZMQK6FPQbe/LGp6d4JLxI+OC3EiCvA9BR8DwnPxaOOx4SL81YAEytgdr7RkDBrSIhQwpLEY2vLq2CiL6xN7tN7t9GJDvznrw6jw5enyuOYLA== 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 YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:19::29) by YQXPR01MB2583.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:4f::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3721.19; Thu, 31 Dec 2020 22:56:12 +0000 Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::3d86:c7f9:bc4c:40c0]) by YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::3d86:c7f9:bc4c:40c0%6]) with mapi id 15.20.3721.020; Thu, 31 Dec 2020 22:56:05 +0000 From: Rick Macklem To: Konstantin Belousov CC: "freebsd-current@freebsd.org" , Alan Somers , Kirk McKusick , Mark Johnston Subject: Re: r367672 broke the NFS server Thread-Topic: r367672 broke the NFS server Thread-Index: AQHW3k3ynlL3lGhXRkC37zjbBa1PUKoPmNaAgAA7NVaAABFYAIAAwg6JgABvToCAALma1A== Date: Thu, 31 Dec 2020 22:56:04 +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: 34e3ab03-b2a2-4ad3-32ec-08d8addf40d8 x-ms-traffictypediagnostic: YQXPR01MB2583: 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: wCxShn6Cqj+ZWzg8uQTdJwhQXxvs/Nl4hn0san9smsLZyody6ybUkpVJqmIUJqV6LoIOzCOV9svL7ZGoTDOnCAuvoH5SpsQlrZDrD6QEjQwfmyVH6FSWGCuSGO+/K0I5MZlaw552efHGgFxPvKp4LCjbFRc5Er2f7ep3XLuBqE8Hf1hhhA8/n83ej6iN7WU4Qwt02kWTiiok9xa3WvEe781r/T1YMrBLsgz6BM3t1oB2Mfc6XfDXjxBgmzyuDI4HmL0FMzgNfqDCnZGY8Us8W0nlgH1knkAONEUfe/j/H+no7T+mlA0s6bxnfw1OoL10zmHFKGqv9UtSmGw6fAB2wwo+Ob46g7q2U+pSNPBlVGMA04FmWmlsU1cDr8rqfyzL0wgHX7AXfkEFXtWY6DpuR/9vj0My+Aq+8Pw8wnPVJENHc/ABrmge2BWqOMfpUawdPR1hTOs0vONfMWdouWSCWA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(396003)(346002)(366004)(39850400004)(136003)(376002)(4326008)(478600001)(966005)(33656002)(8676002)(9686003)(55016002)(8936002)(83380400001)(71200400001)(86362001)(5660300002)(186003)(54906003)(52536014)(64756008)(66446008)(316002)(2906002)(6916009)(786003)(26005)(66556008)(53546011)(66476007)(6506007)(91956017)(76116006)(66946007)(7696005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?8S3KdPf8LMCdhyQMR44F0xuBm8rPXt0CXfOsHPxMzsbgzLxPQGYXAN7M6V?= =?iso-8859-1?Q?hmmitKbzpY4sQecfvmYOP7MAfnuo6UUGDavjIgTiQUPmMhdxGCoZUPRYFH?= =?iso-8859-1?Q?YLxu9CvFLFec2W5VuHS2gT3du3y3AR4+ROfKbHhRp9aB02ewYuao89YbSr?= =?iso-8859-1?Q?rbB4QP4DYk1N/VSqKYOsBjnQ0lmvmRpv0cJt+lYJzZ9za6+ah1t7tg0kWB?= =?iso-8859-1?Q?UhXhPnDP3dCKW27nGNOZ11uscxKwOd1IPMbKLcog5n7oXzw6Fcq3b6K1Xh?= =?iso-8859-1?Q?/biNN+MZqA6rSASwb8/gICDwI09JqaR4ge/0whe65dsGqcUbg4lkT9Pn/G?= =?iso-8859-1?Q?J8z8htfDqde8V1XorS0HgHgWAoPsVm/IH2es8roaflbrBGF1sC8rVG4pAP?= =?iso-8859-1?Q?OvHN4kmveq2CKCS9Jf90K3nTO/HTcGmGaj8L2ukkjL03hCnvWtxUpkQaQO?= =?iso-8859-1?Q?sNxpLWrrdsr89PRt+xRSgUm1O+OeG6sGZcc1wm70k0PkcNi19ZEEQtXcIz?= =?iso-8859-1?Q?ZisogdPLRCof0SB8rz6jN1fC82fIWWvvqrRHQXtd0FPu8Fze3alquyd+A7?= =?iso-8859-1?Q?PQrmMToRZsdBVvh67J1Xt3Ie63QkftO1hf4Qi276dPMsVzu38VXZrS3o8a?= =?iso-8859-1?Q?Ic6m4WFOihTFUeYjmBBWH1BoJs/LLnua3ECtRvU5eNnmBM17UGsXlm9HKu?= =?iso-8859-1?Q?yNG6cOaY8EH8vmEulMyGcO/Qxclg7yUUU6tWSYXkcmz3+oympNp5p2s1rk?= =?iso-8859-1?Q?ziXbhYAqxg/ngtGWEyHEE3bdFus9pqFICacUfAGO78iGiAQv5T/XC1RGvK?= =?iso-8859-1?Q?XbG4+rY3xgvBk1RaLaaU/PgP0H/LbHGrDvsaItGa3L1lRMYPpm1sf5rNqv?= =?iso-8859-1?Q?M77mbRQleZb9Wu2QAgucaYwH0CBYk3UW6kuLkBa3g1rDi4pECzLX3Y9qt2?= =?iso-8859-1?Q?NMbxjj++JaKZQ76N2Tpf0eh4RhsVd9oHcU7vd9SzsyNsjesBbaEQFvLZUt?= =?iso-8859-1?Q?x8T6XN2KuFvUArorg=3D?= 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: YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 34e3ab03-b2a2-4ad3-32ec-08d8addf40d8 X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Dec 2020 22:56:04.8978 (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: k1EO04jqO7v2un1VPYlmL5PM3ADCpX5zljL+juH+YjZksrY8Syz8RoJ5Nq7MkoEW3v1tUhA3lMPEILv3WZLEHQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQXPR01MB2583 X-Rspamd-Queue-Id: 4D6Nmt1HfLz4VV3 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 31 Dec 2020 22:56:14 -0000 Just fyi, I have put a patch up on phabricator as D27875 that seems=0A= to fix the problem for all NFS client mounts except NFSv4.0.=0A= NFSv4.0 will require an additional fix so that the "seqid" is=0A= properly maintained during redos of the Open caused by=0A= the ERELOOKUP redo.=0A= =0A= If anyone is running a recent head kernel on a system that=0A= NFS exports UFS file systems, please test this patch.=0A= =0A= Peter, can you test this?=0A= =0A= If acquiring the patch from phabricator is awkward,=0A= just email and I will send you a copy of the patch.=0A= =0A= Thanks, rick=0A= ps: If possible, I'd like to commit this patch in a=0A= couple of days, given the FreeBSD release schedule.=0A= =0A= ________________________________________=0A= From: owner-freebsd-current@freebsd.org = on behalf of Konstantin Belousov =0A= Sent: Thursday, December 31, 2020 6:40 AM=0A= To: Rick Macklem=0A= Cc: freebsd-current@freebsd.org; Alan Somers; Kirk McKusick; Mark Johnston= =0A= Subject: Re: r367672 broke the NFS server=0A= =0A= CAUTION: This email originated from outside of the University of Guelph. Do= not click links or open attachments unless you recognize the sender and kn= ow the content is safe. If in doubt, forward suspicious emails to IThelp@uo= guelph.ca=0A= =0A= =0A= On Thu, Dec 31, 2020 at 05:16:27AM +0000, Rick Macklem wrote:=0A= > Rick Macklem wrote:=0A= > >Kostik wrote:=0A= > > >=0A= > > >Idea of the change is to restart the syscall at top level. So for NFS= =0A= > > >server the right approach is to not send a response and also to not=0A= > > >free the request mbuf chain, but to restart processing.=0A= > > Yes. I took a look and I think restarting the operation by rolling the= =0A= > > working position in the mbuf lists back and redoing the operation=0A= > > is feasible and easier than fixing the individual operations.=0A= > >=0A= > > For NFSv4, you cannot redo the entire compound, since non-idempotent=0A= > > operations like exclusive open may have already been completed.=0A= > > However, rolling back to the beginning of the operation should be=0A= > > doable.=0A= > Turned out to be quite easy. I'll stick a patch up on phabricator=0A= > tomorrow, after I do a little more testing.=0A= > NFSv4.0 is still broken, because it screws up the seqid, but I can=0A= > fix that separately.=0A= >=0A= > I do see the code looping about 2-3 times before it gets a successful=0A= > ufs_create(). Does that sound reasonable?=0A= In the simple case, it could be described as is: ERELOOKUP is returned=0A= if the parent directory cannot be locked sleep-less, and we have to drop=0A= the lock for opened vnode to sleep on it. More elaborate (but still=0A= not precise) description is that parent directory might also need to=0A= be synced, in which case its parent might need to be locked, and so on=0A= recursively.=0A= =0A= Slightly reformulating, I expect that ERELOOKUPs come out in case several= =0A= threads create files in the same directory.=0A= =0A= > Here's some debug printfs for the test run of 4 concurrent compiles.=0A= > (proc=3D8 is create and proc=3D12 is remove. Each line is a ERELOOKUP=0A= > retry. This is for the 4 threads, but I had the thread tid in another pr= intf=0A= > and it showed 2-3 attempts for the same thread. They should be serialize= d=0A= > by the exclusive lock on the directory vnode.)=0A= I cannot make any conclusion from the output and its description.=0A= Are there opens that do not result in ERELOOKUP, i.e. does the op=0A= eventually succeed ? What is the ratio of ERELOOKUP vs. success ?=0A= =0A= Also note that any VOP that modify the volume' metadata might result=0A= in ERELOOKUP.=0A= =0A= > tryag3 stat=3D0 proc=3D8=0A= > tryag3 stat=3D0 proc=3D8=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 Thu Dec 31 22:59:15 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 9EA934D3BF9 for ; Thu, 31 Dec 2020 22:59:15 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D6NrM3zSSz4Vkn; Thu, 31 Dec 2020 22:59:15 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro.local (unknown [IPv6:2601:648:8681:1cb0:6d91:ae61:b3ec:ca03]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 24DAB239E8; Thu, 31 Dec 2020 22:59:15 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Subject: Re: Enabling AESNI by default To: Allan Jude , FreeBSD Current References: <5d56280e-a8dd-b28d-7039-f8fe0bc0cd6f@freebsd.org> From: John Baldwin Autocrypt: addr=jhb@FreeBSD.org; keydata= mQGiBETQ+XcRBADMFybiq69u+fJRy/0wzqTNS8jFfWaBTs5/OfcV7wWezVmf9sgwn8TW0Dk0 c9MBl0pz+H01dA2ZSGZ5fXlmFIsee1WEzqeJzpiwd/pejPgSzXB9ijbLHZ2/E0jhGBcVy5Yo /Tw5+U/+laeYKu2xb0XPvM0zMNls1ah5OnP9a6Ql6wCgupaoMySb7DXm2LHD1Z9jTsHcAQMD /1jzh2BoHriy/Q2s4KzzjVp/mQO5DSm2z14BvbQRcXU48oAosHA1u3Wrov6LfPY+0U1tG47X 1BGfnQH+rNAaH0livoSBQ0IPI/8WfIW7ub4qV6HYwWKVqkDkqwcpmGNDbz3gfaDht6nsie5Z pcuCcul4M9CW7Md6zzyvktjnbz61BADGDCopfZC4of0Z3Ka0u8Wik6UJOuqShBt1WcFS8ya1 oB4rc4tXfSHyMF63aPUBMxHR5DXeH+EO2edoSwViDMqWk1jTnYza51rbGY+pebLQOVOxAY7k do5Ordl3wklBPMVEPWoZ61SdbcjhHVwaC5zfiskcxj5wwXd2E9qYlBqRg7QeSm9obiBCYWxk d2luIDxqaGJARnJlZUJTRC5vcmc+iGAEExECACAFAkTQ+awCGwMGCwkIBwMCBBUCCAMEFgID AQIeAQIXgAAKCRBy3lIGd+N/BI6RAJ9S97fvbME+3hxzE3JUyUZ6vTewDACdE1stFuSfqMvM jomvZdYxIYyTUpC5Ag0ERND5ghAIAPwsO0B7BL+bz8sLlLoQktGxXwXQfS5cInvL17Dsgnr3 1AKa94j9EnXQyPEj7u0d+LmEe6CGEGDh1OcGFTMVrof2ZzkSy4+FkZwMKJpTiqeaShMh+Goj XlwIMDxyADYvBIg3eN5YdFKaPQpfgSqhT+7El7w+wSZZD8pPQuLAnie5iz9C8iKy4/cMSOrH YUK/tO+Nhw8Jjlw94Ik0T80iEhI2t+XBVjwdfjbq3HrJ0ehqdBwukyeJRYKmbn298KOFQVHO EVbHA4rF/37jzaMadK43FgJ0SAhPPF5l4l89z5oPu0b/+5e2inA3b8J3iGZxywjM+Csq1tqz hltEc7Q+E08AAwUIAL+15XH8bPbjNJdVyg2CMl10JNW2wWg2Q6qdljeaRqeR6zFus7EZTwtX sNzs5bP8y51PSUDJbeiy2RNCNKWFMndM22TZnk3GNG45nQd4OwYK0RZVrikalmJY5Q6m7Z16 4yrZgIXFdKj2t8F+x613/SJW1lIr9/bDp4U9tw0V1g3l2dFtD3p3ZrQ3hpoDtoK70ioIAjjH aIXIAcm3FGZFXy503DOA0KaTWwvOVdYCFLm3zWuSOmrX/GsEc7ovasOWwjPn878qVjbUKWwx Q4QkF4OhUV9zPtf9tDSAZ3x7QSwoKbCoRCZ/xbyTUPyQ1VvNy/mYrBcYlzHodsaqUDjHuW+I SQQYEQIACQUCRND5ggIbDAAKCRBy3lIGd+N/BCO8AJ9j1dWVQWxw/YdTbEyrRKOY8YZNwwCf afMAg8QvmOWnHx3wl8WslCaXaE8= Message-ID: <246743d3-ffd8-2101-7c07-2c2a9cc033ce@FreeBSD.org> Date: Thu, 31 Dec 2020 14:59:13 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: <5d56280e-a8dd-b28d-7039-f8fe0bc0cd6f@freebsd.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 31 Dec 2020 22:59:15 -0000 On 12/31/20 11:51 AM, Allan Jude wrote: > We've had the AESNI module for quite a few years now, and it has not > caused any problems. > > I am wondering if there are any objections to including it in GENERIC, > so that users get the benefit without having to have the "tribal > knowledge" that 'to accelerate kernel crypto (GELI, ZFS, IPSEC, etc), > you need to load aesni.ko' > > Userspace crypto that uses openssl or similar libraries is already > taking advantage of these CPU instructions if they are available, by > excluding this feature from GENERIC we are just causing the "out of the > box" experience to by very very slow for crypto. > > For example, writing 1MB blocks to a GELI encrypted swap-backed md(4) > device: > > with 8 jobs on a 10 core Intel Xeon CPU E5-2630 v4 @ 2.20GHz > > fio --filename=/dev/md0.eli --device=1 --name=geli --rw=write --bs=1m > --numjobs=8 --iodepth=16 --end_fsync=1 --ioengine=pvsync > --group_reporting --fallocate=none --runtime=60 --time_based > > > stock: > write: IOPS=530, BW=530MiB/s (556MB/s) (31.1GiB/60012msec) > > with aesni.ko loaded: > write: IOPS=2824, BW=2825MiB/s (2962MB/s) (166GiB/60002msec) > > > Does anyone have a compelling reason to deny our users the 5x speedup? I think this is fine. I do hope to add AES support to ossl(4) at some point, and it may be that ossl(4) will supplant aesni(4) (and armv8crypto(4)) at that point, but aesni in GENERIC makes sense right now (and I'd say to MFC it to 12). armv8crypto in arm64 GENERIC will make sense once AES-XTS support (currently in a review) lands. -- John Baldwin From owner-freebsd-current@freebsd.org Fri Jan 1 00:42:38 2021 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 F3FD24D7B12 for ; Fri, 1 Jan 2021 00:42:37 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D6R7d6gC8z4g28; Fri, 1 Jan 2021 00:42:37 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Received: from [192.168.0.4] (unknown [200.118.158.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: pfg) by smtp.freebsd.org (Postfix) with ESMTPSA id 984FE25033; Fri, 1 Jan 2021 00:42:37 +0000 (UTC) (envelope-from pfg@FreeBSD.org) Subject: Re: Bug in r361898 (was Re: poudriere: services_mkdb recompile with larger PROTOMAX) To: Daniel Eischen , freebsd-current@freebsd.org References: From: Pedro Giffuni Organization: FreeBSD Message-ID: <6808fb50-0823-0ae3-a9dd-0fc73eafd33e@FreeBSD.org> Date: Thu, 31 Dec 2020 19:42:36 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 01 Jan 2021 00:42:38 -0000 On 12/31/20 5:47 PM, Daniel Eischen wrote: > On Thu, 31 Dec 2020, Daniel Eischen wrote: > >> I see this message in src/UPDATING: >> >> 20201216: >>  The services database has been updated to cover more of the basic >>  services expected in a modern system. The database is big enough >>  that it will cause issues in mergemaster in Releases previous to >>  12.2 and 11.3, or in very old current systems from before r358154. >> >> I'm trying to update a poudriere jail from a freshly built -current >> system (r368820): >> >>   FreeBSD vega.my.domain 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r368820 >>   Wed Dec 30 15:55:06 EST 2020 >> >> I've tried running this command twice: >> >>   export MAKEOBJDIRPREFIX=/opt/FreeBSD/obj/head.obj >>   poudriere jail -u -j 13amd64 >> >> [ /opt/FreeBSD/obj/head.obj is my freshly built (r368820) obj tree is ] >> >> services_mkdb was updated in the jail on the first pass: >> >>   # ls -l /usr/local/poudriere/jails/13amd64/usr/sbin/services_mkdb >>   -r-xr-xr-x  1 root  wheel  15288 Dec 31 13:02 >> /usr/local/poudriere/jails/13amd64/usr/sbin/services_mkdb >> >> But as on the first pass of 'poudriere jail -u -j 13amd64`, I still get >> the following error: >> >> ... >> >> --- _CONFSINS_services --- >> install -N /opt/FreeBSD/svn/head/etc  -C -o root  -g wheel -m 644 >> /opt/FreeBSD/svn/head/usr.sbin/services_mkdb/services >> /usr/local/poudriere/jails/13amd64/etc/services >> --- installconfig_subdir_usr.bin --- >> --- installconfig_subdir_usr.bin/nice --- >> ===> usr.bin/nice (installconfig) >> --- installconfig_subdir_usr.sbin --- >> --- afterinstallconfig --- >> --- installconfig_subdir_lib --- >> --- installconfig_subdir_lib/ncurses --- >> --- installconfig_subdir_lib/ncurses/ncurses --- >> ===> lib/ncurses/ncurses (installconfig) >> --- installconfig_subdir_usr.sbin --- >> services_mkdb -l -q -o >> /usr/local/poudriere/jails/13amd64/var/db/services.db >> /usr/local/poudriere/jails/13amd64/etc/services >> --- installconfig_subdir_usr.bin --- >> --- installconfig_subdir_usr.bin/nl --- >> ===> usr.bin/nl (installconfig) >> --- installconfig_subdir_usr.sbin --- >> services_mkdb: Ran out of protocols adding `divert'; recompile with >> larger PROTOMAX >> >> What's the work-around for this?  services_mkdb seems to have been >> updated on the first pass off 'poudiere jail -u ...', but still fails >> on the second pass. > > A typo (tdp was used instead of tcp) in the services file seems to > have been introduced in r361898.  This is the patch that fixes the > problem for me. > > Index: usr.sbin/services_mkdb/services > =================================================================== > --- usr.sbin/services_mkdb/services (revision 368820) > +++ usr.sbin/services_mkdb/services (working copy) > @@ -1788,7 +1788,7 @@ >  iscsi-target 3260/udp   # iSCSI port >  mysql  3306/tcp   #MySQL >  mysql  3306/udp   #MySQL > -ms-wbt-server 3389/tdp   rdp #MS WBT Server > +ms-wbt-server 3389/tcp   rdp #MS WBT Server >  ms-wbt-server 3389/udp   #MS WBT Server >  efi-lm  3392/tcp   #EFI License Management >  efi-lm  3392/udp   #EFI License Management > Oops .... thanks ! It proved a nice chance to start using git. Pedro. From owner-freebsd-current@freebsd.org Fri Jan 1 02:25:12 2021 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 0DD2D4BAAC4 for ; Fri, 1 Jan 2021 02:25:12 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D6TPz2QQdz4mXj for ; Fri, 1 Jan 2021 02:25:11 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: by mail-ej1-x62f.google.com with SMTP id w1so27010291ejf.11 for ; Thu, 31 Dec 2020 18:25:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=4cmODN6zCilMcYIt5I/tJE2hX6QNBtCe+fRRJExA37o=; b=mkkIBVB6RcrLpyY6yBXhX61FbSk8QhNQi538i7Ou5SMA+PTc+jAJW7CzqY73BVVDsN LMTt/txW9fAaq6hVHc8yLtH/5OyEnaGISgMq7PO1O2owJW8UANEK05q9yk/gw4pfYbGA upUD3sMV23VT6IL546niINSIDcUQq94zQIvzjGe58uYMhg9a+2kRtgCPIjt0AZdT9/A8 TtNa6VRw6uMlXqCunTgjSUbdhmV0v4OajYkVyHm40PD8BnfeDqMwFqtKcXC0XqMtUZ35 Rgu+I7TlhQXKX5zYVjaUhXgMuTjE5rRSQ6qL22jRo9kmr8tD2IezuPaiuRnIPwcjpTHB zWmg== X-Gm-Message-State: AOAM533qzbiq83fWVEsXA8MbOPTqeP2Znst0/0ZLozQoPlph2qpyt18t Jz4UT/Syc4QIMo0+KDEu+8CAeektGSfeVq130LxjdYQJo9CURA== X-Google-Smtp-Source: ABdhPJw88R4EY/57Zc42yXYDionYRZcaa36Li8rAnPb0AB8twDSc9rKtOiIsgm5paiQXvIG//Q5keRRBYSUDDE5Jp8E= X-Received: by 2002:a17:906:c83b:: with SMTP id dd27mr56401539ejb.356.1609467909696; Thu, 31 Dec 2020 18:25:09 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a54:3d8d:0:0:0:0:0 with HTTP; Thu, 31 Dec 2020 18:25:08 -0800 (PST) In-Reply-To: <20201231193908.GC31099@funkthat.com> References: <5fdc0b90.1c69fb81.866eb.8c29SMTPIN_ADDED_MISSING@mx.google.com> <20201218175241.GA72552@spindle.one-eyed-alien.net> <20201218182820.1P0tK%steffen@sdaoden.eu> <20201223023242.GG31099@funkthat.com> <20201223162417.v7Ce6%steffen@sdaoden.eu> <20201229011939.GU31099@funkthat.com> <20201229210454.Lh4y_%steffen@sdaoden.eu> <20201230004620.GB31099@funkthat.com> <20201231193908.GC31099@funkthat.com> From: grarpamp Date: Thu, 31 Dec 2020 21:25:08 -0500 Message-ID: Subject: Re: HEADS UP: FreeBSD src repo transitioning to git this weekend To: freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4D6TPz2QQdz4mXj X-Spamd-Bar: / X-Spamd-Result: default: False [-0.00 / 15.00]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a00:1450:4864:20::62f:from]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[2a00:1450:4864:20::62f:from:127.0.2.255]; NEURAL_SPAM_SHORT(1.00)[1.000]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62f: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.34 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, 01 Jan 2021 02:25:12 -0000 > There is already HTTPS to protect the "authenticity" of the magnet > link. No. FreeBSD fails to publish signed fingerprints of their TLS pubkeys, therefore users can't pin them down, therefore any MITM can bypass CA game and MITM attack users at will, feed them bogus infohash, isos, git repo tofu, pkg, etc. MITM is bad, MITM is in use, and MITM fails when sig'd, verified, and pinned. > Yes, someone could vandalize the wiki page but I'm now > subscribed and will notice it... Only if they go through your front door. > Also, magnet links are not officially supported the project. > provide them because I think it's useful, and there are some people > who request them... transmission-bt, aria2, etc fast, easy, distributed sharing. But needs backed by real sigs. > It's difficult to educate people on these points.. Especially when poor examples to observe and learn from continue among infrastructures and even educators. > snapaid was designed to make it even easier... So they've learned some provider specific edge tool, not general gpg, or even wider security. Oh well. > Is there any reason to think [bittorrent] insecure? Cost under $50k of compute to break sha-1, multiply that by SolarWinds size distribution clouds under tofu, collect your winnings based on your node count. From owner-freebsd-current@freebsd.org Fri Jan 1 11:57:22 2021 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 2721C4C5D55 for ; Fri, 1 Jan 2021 11:57:22 +0000 (UTC) (envelope-from filippomore@yahoo.com) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4D6k696QMQz4ksq for ; Fri, 1 Jan 2021 11:57:21 +0000 (UTC) (envelope-from filippomore@yahoo.com) Received: by mailman.nyi.freebsd.org (Postfix) id DA43A4C5D54; Fri, 1 Jan 2021 11:57:21 +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 D8D354C6227 for ; Fri, 1 Jan 2021 11:57:21 +0000 (UTC) (envelope-from filippomore@yahoo.com) Received: from sonic314-20.consmr.mail.ne1.yahoo.com (sonic314-20.consmr.mail.ne1.yahoo.com [66.163.189.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4D6k684zXdz4l05 for ; Fri, 1 Jan 2021 11:57:20 +0000 (UTC) (envelope-from filippomore@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1609502239; bh=8/s2pwhJ7+42fzyEAmxEP6E12wLWVR8wkZ5yQrSqdUS=; h=Date:From:To:Subject:From:Subject; b=b9W57YpKAHqPS9lROh6iqB0kVPtF1GUQo68u0igBlWDWLvABekTySqWhUUbvSL2h47bLvX4YYYxkYGEQY930hJeGOfr30gSS4622RqCXMpZbStZsK1sdqbEeWg9DrTpm5vFsI5p/yO9bhWOBT6HBA1+sN7FkMYRLjJAQRbo+It8CLg1rjZrtyQkfDn7UgHopkpcDOtaJSPEI81fWk12ynqaG5r/7wEHazIA/AnWB6eeXlJCt4Doq3e0RzsLeR/Gaxv/3ms7BCJvusE5TKhz8pBmSmoMlwoF8uAwOFsuFrU/0N0TyFt8Pa7cGXqoZbL3tRbDUSHXap4qbOaLcyA+Bng== X-YMail-OSG: wOrQ8dcVM1kGNoBm.NZUKgAWRzHy.Tbe79VVn1eFICQRvhPK1l6eGIea7t2tlyF c.CmU3t6qINoP5dMmF5pFatWGjXo0_YHm9rOql5gpbwqNLiYZrzsYLFSuihZETplCEk3e5iVKdhC WpvoySxvukWj.bgZQt6VETgy.IlOaQy45uCz6Ip7ZhkzelHNZaI4vH7_ETmXGw2NRZksTjywqsVO CgEZxU.Pdd_P.6.TafQIh9bhMtCULT2w7FH9tFycw.1QM_JatccETBQiu35oVpeXDbxKoxl9htkm HuTM8v4AkvSAxIGHD5YsIsZ3vy.oI5RSvkunKKsi24JaR0n2MM6Qn18whEv2G7HesQT_HuXurni_ WK9xa8RUQykpA55NcdXhiUs3m_UGV00Aj9bNO.qwc63Qmhctd_GcXPwplknMOrftLXp_GVNL7ZFb pkD480lYCxc94TcmhFftnEq_JyXkTB_PIjNtcHwQVrLudP1RkqSVrS6j9pKj4KkZRGpCxlksJ8YV f0JCokwqBloAkHfUAlg.KXxmNqrG_RyPnamKZq6GWGzztlZcZIfb..G0pxIhx0DnXnN3O5.i2dMQ cPWsXJjWV1Wa44KKWIYEHaxde45mt9rh8NMpg8CjxACk.JHB.waRn1VBeBIyHXW6mjgxAOhE0jJn WMpenC6v._uZHzBosG6kBuD0nb_U6BAbbY.PtqaczqcWzrLUp6tEJ7AzcBQY2XHqp4GRqX4DoOyQ lNciitXN8q21mrNmU8izgHuN0eETjFmt4OTHTjE28CS0lUKrisHN.kWfqpGTQxAmro27CJBW_DXu fPD8H7kO5ByeqPSZ7V5am0AvRwGynq5Uu.92M9s97hoPAwI3BWPZtYgeznugwtaPgE9NYedtxwhp wm2KgbJq8VMHw7SVjB6ad4EDRZDV1UPzvJiK5BSlINABrsfe3.q0flmm33CZwvdmapxrhzLgCe74 .Iros1IuhQbNTfAWftfps8q4gXZnUtryj5qjJfD4vxR_iHoNonbAcFaDTmTnDNulC.QWYig_snCk glLXHQk.lizi45otKranb1Tsbx.HWj7HP.P8v3aMLLLDsqGP3m6yacCaQXj58_CIljNFCoonri7P 52bLm8xHoVSdxdwNUI3FWs3sBIyEmfNKvU8_QTS59d3U2HtweDn3AHfHSpTwFQknGtJreFtkQDtt suIm4n81_V2PnOeDfwwqHMS2ORhwpNbyq4iVF0_biz8BhVWDeIv9AhBreSFVs3rt5OUCpROZdU0E hO4gP3TIr5qgCrLYD0Tn8atS2rmrhkWYjNt4uKPIUyrcsuXO4mkAqkmjkeFF8Fx2n8Wp6GGUO3Vl VDFxjxNNbhR1qw9GMOV9Qygto8E0aaPkAFwBbp2S5vCbBvT9ppoP7yI4C0ecCL_BzNRwzHLCHqGS 7h_E_RZH32YUE8RegdP_64sYJi9Lei5NX3TRstaiV2e7NzBzFdEG7ZORKX1Dy3uXM4al2mlgYqzh 7uf9_8Wodms6QcETjwlx2RmSI.AIJGkCgFdWzMmnW0pisQmvp2gX3dwaF5B0XpAXltkESfGITxiu yUExppZXST931JTAAsgBh2jk1Kc63N16J_fXHwocwvzRHfP2B_CVec54TKfnSo_RkwV9XELMhigb A6L2TaGAvWUyZPt7T0q5Pl2oTfX8bSUxfFrxHpXEN.YTs56_dHM3FoKKOzzb.m4O05IW22gwLfN0 L3gfwCMZ56VigFaMdDDG2o4AhJ2GxkuWrvr_MuNLPDD9j6QyZjhJyBnCJUpZ06Y0eM9OLjTDXG2j jPBU5_YWWqQfmKRrx4upOmjoOwpB4C.IV49Xswf9Djxl5RVdMmLoAqnUKGyz_1nGid2RO4_vNRLB UbXRqnWrYfDANgu8O.zSAwYDLGKZ8LW0ofm6ggRtizAhpOYUPkocL0hPTMbD.zceE4S6nnQMIEbz HXATOFDT53ZqaZ60taIoYUtknQbDdO4RgXtZdVEVdJYSKVpTPn9c.DsAeETm_2bNehvX81oavXIk hvaccglmnsAawMD.AU2oj8y0XlHaqpdWiIyEBm2lxf0C_Y.beeRbWlep5gmjXYqqqNs9abeqM8zm fJqVRMp4HIkATQICImxcpcGxzqPaVXTg5e8EKo9yBEakEZAii6WwJmTmhTw_tdu_Jdq71rvgWiQk CX18ZeTg7CW1EtzUQpUL8SUbUKEYKIS_IFnqbWYkffZOAhWuyP4jCzK2G.gsz.E7ECst0jnbgzeT OWM1LJ5ogUwEKGWVrwQpWDuh2jMVvMgdTP2VLyZPOKEQKnoSqh4yLziFIzTKu5FF6Kbxc0J6ivh0 3upV2Jowzo2BRQaVIsLYrbVPNDbbQ8C4tN3.zcN5vS7gxBSyKqpaSd9xX_P1xN2s2DbYv92jVSaN X Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.ne1.yahoo.com with HTTP; Fri, 1 Jan 2021 11:57:19 +0000 Date: Fri, 1 Jan 2021 11:57:16 +0000 (UTC) From: Filippo Moretti To: FreeBSD Current Message-ID: <223516195.6185376.1609502236330@mail.yahoo.com> Subject: Problem compiling git from ports MIME-Version: 1.0 References: <223516195.6185376.1609502236330.ref@mail.yahoo.com> X-Mailer: WebService/1.1.17278 YMailNorrin Mozilla/5.0 (X11; FreeBSD amd64; rv:84.0) Gecko/20100101 Firefox/84.0 X-Rspamd-Queue-Id: 4D6k684zXdz4l05 X-Spamd-Bar: - X-Spamd-Result: default: False [-1.95 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-0.95)[-0.951]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36646, ipnet:66.163.184.0/21, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[66.163.189.146:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[66.163.189.146:from:127.0.2.255]; RCVD_IN_DNSWL_NONE(0.00)[66.163.189.146:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[66.163.189.146:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[current] Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 01 Jan 2021 11:57:22 -0000 I could not update git from 2.29 in my system [root@STING /usr/ports/devel/git]# uname -a FreeBSD STING 13.0-CURRENT FreeBSD 13.0-CURRENT #14 main-c255423-gee938b203= 35: Wed Dec 30 10:41:00 CET 2020=C2=A0=C2=A0=C2=A0=C2=A0 root@STING:/usr/ob= j/usr/src/amd64.amd64/sys/STING=C2=A0 amd64 This is the error which can be duplicatedsincerelyFilippo [root@STING /usr/ports/devel/git]# gmake[3]: 'GIT-VERSION-FILE' is up to da= te. gmake[3]: Leaving directory '/usr/ports/devel/git/work-default/git-2.30.0' sed -e '1s|#!.*/sh|#!/bin/sh|' git-subtree.sh >git-subtree chmod +x git-subtree install -d -m 755 /usr/ports/devel/git/work-default/stage/usr/local/libexec= /git-core install -m 755 git-subtree /usr/ports/devel/git/work-default/stage/usr/loca= l/libexec/git-core asciidoctor -b docbook -d manpage=C2=A0 \ =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -agit_version=3D2.30.0 -I../../D= ocumentation -rasciidoctor-extensions -alitdd=3D'--' git-subtree.= txt gmake[2]: asciidoctor: No such file or directory gmake[2]: *** [Makefile:86: git-subtree.xml] Error 127 gmake[2]: Leaving directory '/usr/ports/devel/git/work-default/git-2.30.0/c= ontrib/subtree' *** Error code 2 Stop. make[1]: stopped in /usr/ports/devel/git *** Error code 1 Stop. make: stopped in /usr/ports/devel/git [root@STING /usr/ports/devel/git]#=20 From owner-freebsd-current@freebsd.org Fri Jan 1 14:09:01 2021 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 33B8F4C969E for ; Fri, 1 Jan 2021 14:09:01 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qv1-xf2c.google.com (mail-qv1-xf2c.google.com [IPv6:2607:f8b0:4864:20::f2c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D6n2417JRz4rl9 for ; Fri, 1 Jan 2021 14:09:00 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qv1-xf2c.google.com with SMTP id p5so10007188qvs.7 for ; Fri, 01 Jan 2021 06:08:59 -0800 (PST) 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:references :mime-version:content-disposition:in-reply-to; bh=2E4UgLL7gN7hqb3R4sagHhWjz5PwI/5tYC2pmB/qA7M=; b=H1rwB/XS6TSSUEqny4XWUeslPcgBWGB9lJLBOPGYm+sGpTpRQiJ+7DCebQuEBv/+QL db2qlGZMmTr24/2nY2u9WWVwqI6ne/1MIQAoWVzSu+1kAWaCJTlLzhb+PTItbLuRZPae C9sW5n4I8SusYqTxvYJGdvNZI+v1Abl34hLY6fZ+7g5KX18t6UTFNTidWK+dbnHlyLh0 juc4k+jiTcr3e9rH0QFQZRwxnN/bt8ET7K1Y7ze/Maj9lRLRCpKJhtVo38USaQNzq0Ml YZrDHlLDXHxjEjKFhLSCALFbDgw7nqFJemtKlJ7UbgPhTOkSr+0DBgNaMAZYo8hVbnQO DwPw== X-Gm-Message-State: AOAM530AyFsuexXsEpiVc/f8kKOiCa+Dz7UFUdLyOX8ZEgH+Ln8XJYS1 l9WTldmHiSKxvlFAKFGpoWPInOCyDU3RVw== X-Google-Smtp-Source: ABdhPJzciDCaQkaoMke5xaJlAWLr4HZeMpcsrkHUCo/0FoxckdZutoeeD6qnf5rm3MUZhOER4ni66A== X-Received: by 2002:ad4:4c8c:: with SMTP id bs12mr66526920qvb.11.1609510139161; Fri, 01 Jan 2021 06:08:59 -0800 (PST) Received: from mutt-hbsd (pool-100-16-222-53.bltmmd.fios.verizon.net. [100.16.222.53]) by smtp.gmail.com with ESMTPSA id c7sm30568494qtw.70.2021.01.01.06.08.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 01 Jan 2021 06:08:58 -0800 (PST) Date: Fri, 1 Jan 2021 09:08:57 -0500 From: Shawn Webb To: grarpamp Cc: freebsd-current@freebsd.org Subject: Re: HEADS UP: FreeBSD src repo transitioning to git this weekend Message-ID: <20210101140857.x3hbci6c4nwi7gl7@mutt-hbsd> X-Operating-System: FreeBSD mutt-hbsd 13.0-CURRENT-HBSD FreeBSD 13.0-CURRENT-HBSD X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0xFF2E67A277F8E1FA References: <20201218175241.GA72552@spindle.one-eyed-alien.net> <20201218182820.1P0tK%steffen@sdaoden.eu> <20201223023242.GG31099@funkthat.com> <20201223162417.v7Ce6%steffen@sdaoden.eu> <20201229011939.GU31099@funkthat.com> <20201229210454.Lh4y_%steffen@sdaoden.eu> <20201230004620.GB31099@funkthat.com> <20201231193908.GC31099@funkthat.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7dl3yj5s7cp5rsmt" Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4D6n2417JRz4rl9 X-Spamd-Bar: ----- X-Spamd-Result: default: False [-5.10 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[hardenedbsd.org:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-1.000]; SIGNED_PGP(-2.00)[]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RBL_DBL_DONT_QUERY_IPS(0.00)[2607:f8b0:4864:20::f2c:from]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RECEIVED_SPAMHAUS_PBL(0.00)[100.16.222.53:received]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[hardenedbsd.org:s=google]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[hardenedbsd.org]; SPAMHAUS_ZRD(0.00)[2607:f8b0:4864:20::f2c:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f2c:from]; MID_RHS_NOT_FQDN(0.50)[]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 01 Jan 2021 14:09:01 -0000 --7dl3yj5s7cp5rsmt Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Dec 31, 2020 at 09:25:08PM -0500, grarpamp wrote: > > There is already HTTPS to protect the "authenticity" of the magnet > > link. >=20 > No. FreeBSD fails to publish signed fingerprints of their TLS pubkeys, > therefore users can't pin them down, therefore any MITM can bypass > CA game and MITM attack users at will, feed them bogus infohash, > isos, git repo tofu, pkg, etc. MITM is bad, MITM is in use, > and MITM fails when sig'd, verified, and pinned. There's also nation states that require use of a nation state-owned root CA cert so that they can MITM every single SSL/TLS connection. Connections that don't use/support their custom trusted root cert are either blocked or reported (or both). In this case, MITM isn't theoretically broken, it's broken in practice. And, it's broken in the worst case scenario: downloading source code that the nation state can modify in-transit. This is why I asked FreeBSD to provide anonymous read-only ssh:// support for git. I'm very grateful they support it. I also use it for HardenedBSD's sync scripts due to my own distrust of browser-based SSL/TLS PKI, even in the USA. One thing that I need to do with the HardenedBSD infrastructure is publish on our site the ssh pubkeys of the server (both RSA and ed25519). I plan to do that sometime this coming week. I wonder if it would be a good idea for FreeBSD to do the same (note: I'm not trying to commit FreeBSD to do any work; I'm just spitballing ideas.) Thanks, --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Sha= wn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc --7dl3yj5s7cp5rsmt Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAl/vLPYACgkQ/y5nonf4 4fqaCw/8CLlZU4TxT9TimCS8ZMivSECH4qcuZeKdWwpKqmy/xDHpwjLdCAHf+Wkq 6jY721xJEXe23yfhRunwaGwiKkIJuXbLdypMtIEe8UTCFB9ojsNs4fZEwMoj8raO 2w+OdX/cNmbSNTknDM5FNnmCEYfDbU8IyAwV4gALEUPCPjJFTX0EXfpWbj3orrD/ iWQewFBoOKinGzdd2pXQGCzq0/Uxl4jXfx9jkhnb9rVSEs0RpXWATaJv/eFrEEpW fA4rtYxwg1bjfwrxUjOIrS5JDU/USQoHVcbX31EFLI+PcgzFeSMMyR63LRQp02l9 kxvzedQ+DkiBVT68BTSQHPlRs9IlOP9vInyswVBoNuct8+sWs0CauXgpiHOX3HZD AWxDDlaJ0RDIAmESXLy2v7zmiJaaEbij4/TtHy66RzlWYRgJczuJk+6yH9N3TthL PycrT13uaamk5l/rgCiJJ1uNuCGWH/DoA/3S0QMRzXlMRFdIu7BXb4vrPMPZiuA+ tNnPqas+w6Cfq1dr7QONuvDtmgZv99iHzDh6Ieo+iKJgPu8e7iV95xU+C1c+2lb4 VBheZyS2wV/3C/rz06l/3G47NoXmhH9MFgwSYvtTTMimCwUe+Joohrl97Cj9Nwx7 5qMy/1YV1NGSR6B1p4ihAulSutUMmVVZUCUe8rwvAguPcbJoRNg= =cRl3 -----END PGP SIGNATURE----- --7dl3yj5s7cp5rsmt-- From owner-freebsd-current@freebsd.org Fri Jan 1 14:52:12 2021 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 04B214CA2D0 for ; Fri, 1 Jan 2021 14:52:12 +0000 (UTC) (envelope-from mjguzik@gmail.com) 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 4D6nzv5fc1z4v0D for ; Fri, 1 Jan 2021 14:52:11 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mailman.nyi.freebsd.org (Postfix) id C022F4CA2CF; Fri, 1 Jan 2021 14:52:11 +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 BFE974CA615 for ; Fri, 1 Jan 2021 14:52:11 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-wr1-x429.google.com (mail-wr1-x429.google.com [IPv6:2a00:1450:4864:20::429]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D6nzv4wqWz4tVx for ; Fri, 1 Jan 2021 14:52:11 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-wr1-x429.google.com with SMTP id r7so22099692wrc.5 for ; Fri, 01 Jan 2021 06:52:11 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=a2A8ChNFn7J11z3HllGZW9qYDGOxTCBOuYVbXCyTQIk=; b=K2AqkYV02xQdPGC2k87GAO3zChG2mrW6f0IugSci+0TypKOtN85r0Mp8weZwg5REVS nz9xm8V87TpH3YFgQwUzDSkHcWmYqYM4m7gZY4BHKlFXcmvTf4oIjjfE6G7P8Y3RuQtb StrfjSPYSpAYi6OfWiDdCx/vErT09C6/EvdAY7DGvHCCVESrGMwzkSlDRLA8urflRKYl 5a0/X0v6L2rkYI7yeYzLXkZaa6QO2/BSq/sGEqSmHt0BJCrVDoI4Bgw525/F13gZrE+o mi803ORz0kSm1y+pISboGoTAIz+BQ06G4FNsmcdtdR3C+CcVdbf7YpZOR0GU2A4+2Vas rcKQ== X-Gm-Message-State: AOAM530Cnz8A3LC9O4pB+Tsvlcpw0Isz8V8PvDFkDXCLq5kMFvUgSWFM Ldvg+FHLS4ZIjknJHZrwObTUwZRzYjIr/wDicVo= X-Google-Smtp-Source: ABdhPJyJmH5L5UTNVMIbYvXMI9JPGSygAl8PjSYablceZTvJBnUP1LKMF2QVIdAVLomN2VVxBLxbD4deNV9Dh3sX6pQ= X-Received: by 2002:adf:bc92:: with SMTP id g18mr67185983wrh.160.1609512729062; Fri, 01 Jan 2021 06:52:09 -0800 (PST) MIME-Version: 1.0 Received: by 2002:adf:f811:0:0:0:0:0 with HTTP; Fri, 1 Jan 2021 06:52:07 -0800 (PST) In-Reply-To: <223516195.6185376.1609502236330@mail.yahoo.com> References: <223516195.6185376.1609502236330.ref@mail.yahoo.com> <223516195.6185376.1609502236330@mail.yahoo.com> From: Mateusz Guzik Date: Fri, 1 Jan 2021 15:52:07 +0100 Message-ID: Subject: Re: Problem compiling git from ports To: Filippo Moretti Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4D6nzv4wqWz4tVx X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 01 Jan 2021 14:52:12 -0000 What filesystem is this? Does it work if you sysctl vfs.cache_fast_lookup=0 ? On 1/1/21, Filippo Moretti wrote: > I could not update git from 2.29 in my system > [root@STING /usr/ports/devel/git]# uname -a > FreeBSD STING 13.0-CURRENT FreeBSD 13.0-CURRENT #14 > main-c255423-gee938b20335: Wed Dec 30 10:41:00 CET 2020 > root@STING:/usr/obj/usr/src/amd64.amd64/sys/STING amd64 > > > > > This is the error which can be duplicatedsincerelyFilippo > > > > [root@STING /usr/ports/devel/git]# gmake[3]: 'GIT-VERSION-FILE' is up to > date. > gmake[3]: Leaving directory '/usr/ports/devel/git/work-default/git-2.30.0' > sed -e '1s|#!.*/sh|#!/bin/sh|' git-subtree.sh >git-subtree > chmod +x git-subtree > install -d -m 755 > /usr/ports/devel/git/work-default/stage/usr/local/libexec/git-core > install -m 755 git-subtree > /usr/ports/devel/git/work-default/stage/usr/local/libexec/git-core > asciidoctor -b docbook -d manpage \ > -agit_version=2.30.0 -I../../Documentation -rasciidoctor-extensions > -alitdd='--' git-subtree.txt > gmake[2]: asciidoctor: No such file or directory > gmake[2]: *** [Makefile:86: git-subtree.xml] Error 127 > gmake[2]: Leaving directory > '/usr/ports/devel/git/work-default/git-2.30.0/contrib/subtree' > *** Error code 2 > > Stop. > make[1]: stopped in /usr/ports/devel/git > *** Error code 1 > > Stop. > make: stopped in /usr/ports/devel/git > [root@STING /usr/ports/devel/git]# > > _______________________________________________ > 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" > -- Mateusz Guzik From owner-freebsd-current@freebsd.org Fri Jan 1 16:12:00 2021 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 A5B364CC504 for ; Fri, 1 Jan 2021 16:12:00 +0000 (UTC) (envelope-from filippomore@yahoo.com) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4D6qm02qFjz3Fwg for ; Fri, 1 Jan 2021 16:12:00 +0000 (UTC) (envelope-from filippomore@yahoo.com) Received: by mailman.nyi.freebsd.org (Postfix) id 60C624CC4F8; Fri, 1 Jan 2021 16:12:00 +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 608AC4CC395 for ; Fri, 1 Jan 2021 16:12:00 +0000 (UTC) (envelope-from filippomore@yahoo.com) Received: from sonic308-9.consmr.mail.ne1.yahoo.com (sonic308-9.consmr.mail.ne1.yahoo.com [66.163.187.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4D6qlz1MSMz3Fr1 for ; Fri, 1 Jan 2021 16:11:58 +0000 (UTC) (envelope-from filippomore@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1609517516; bh=4d1+G/+WAx81UcwvsTNoKOJklNTqnyXh5umsRERAfV7=; h=Date:From:To:Subject:From:Subject; b=NmSbXWpKhAEcNP9ARh5UJwQCEBHgXVLnRLtZoJ2jo+DQPcwRuJZl2Um6VQTK3+imZu3WJlBPVz8wOxfI3sD3imkTq4Lv9tBdQKBr0HwRrlouutz2jsKQjjqNtn1b6hLh/90iS7cb9XbS6PojvtHb1GsUSK4EENuXmOwTsvHYfZsZXHQCQ7k+Kafkc0om4Po7IXZNmHm/tkP+PuAJQDTvP4IBeQEHcRKgrrEdCCtdvew/cDoDsYCWHNsX2uhMSzdG/v5ifi0DY5tcJ4D5RcpkgqgPHvYcmw4wdcku7lkerwbPBnJnIT+Bd+6//2TltzyqZmoXeIZ9t4zseQBPA9Llaw== X-YMail-OSG: FrCDdK4VM1n99Lixz4YHtErxJsNmTFTCf7lo2_Lmr9oAaOwL4.FX_nuh1qtmwDs YA_U8kou7EUC6GJH1uqidF5dZSjonVKvOYPFAeFKK48IKjejEJztjsA.bBWUW9E20MPUVIhzWAo8 m8_rpPl2GKMF3ffrsglATnA9pUaeoQCx0nhNfQD8RzdAeJgvZRzDxAQOUEZJQFN7ZMme9NGgrSuR zBnyerF_AuJ74dzafTCOaOA0OTSF7Wlbjl7dP9Uc1aBPlUJB6kPZZ_VKjSFm3c2AzMH8Ktk9ySF4 v01z5BEay_6sFqfSJHNjb6O5SG9f5M0Ub9VamhGXL3rtyn1bhxgIUiUFIOAoalX6bLl2QZRNcl7q RDBs3P6LDnBVD4VxcNwdtNosVS202MSYGl1SzJkAGiXm4b7DKRPaw56PjZ8RNDlI.WmbEsSfpJlO Loy9kg_ZbaeSOC4uuy3yefAkymc7MB890egNOw1IfcWBPI1hm6XqVHCcUqjlxNrl9EffTOPdWdcv ixgt5kVfezdTDPdFrpt9hS99uok0V3B.wKTtBTQKaHjBrWpROUNzxekwNv_Bw7dyaxAjiKQ6tMco v50uZFOdYojvbkabh9lQGawwRmiJ8E77IuhYNJVv10JCo3ujxz5J_wKXsFh6sFk5bjPVxuJNgarF W8fNSWmgHKsJLgduH42i0vUMk3PLGRjSKEdv9RX0Wp4EQLaq1tjLhzJaw4IkkDZDC8ULG7GJSNrC m8IQ50iRjzuM2niPFg8lrQAXQ_aZhp9T0BLx4L8VGpBFL6gPNI2BhuzXNeng6Eb2ikblvW9Wqovz aQxKeUEZgUwfBsZa8c7iiZ5HeXcS5u8CwncsaLmITt8UpkDuJa1VTgdsfhMDFkasec5l_iB0wiNK yeiWZTbE_lcNMvyFhP4nbTbpMp7sp9zr5e0ZZ8iE_EwxT6756OCUVFE.kKlAnDR7wydiLMmmh.oA 3_qAHvUygQyFTHMHGYm.2GkjDF4TjBZDJjl4q0ElDEomLjL0BHnPbRmZJHKakTq0FlB8ODvDSmey 6lfTk4nflYKMrvlZla8GzspfzWRM9EK1ZGR2I.WuzIXMRYkzTcmYtyYKOSSpYQoSjAR.nA5Dbrmj bXR7nmO_GqyFkawhwAbrSZb4FkpHq5hU44BErnoLUlRPCp_XqHksRWRxPO77GIjQmhd8zVtjbGPJ ceuNheC8MF05mF7Tmr7dAgAhnO3DuiPcU24EMuwPg6UYn_TuQRw3ZPnRr_XiDM9BoZIMXUX0zoc7 QDSOpAjUBCoZGw56wN2.tgPQqxVW_ArZPZZpJD03utT0XvFQfvYimDmW6gGXSx_ADppdkBvOTnvC .7Ksznyakxleg3MuM8IwcntRKwnB2T_tnjbHCDg0y_9H7KF0EXwRpKDS_af733jtNFmm8w1IGDiD ysvkr3Jo_FzFwUC8KpCKyMKGbU46kFfA94cbxSyHbXbQA581DBKzF4aQUVz6yHbvgCFoF..SD6t7 vXcmGysIPVgLd5bSLlnxl93.APRAz9hKJP5A_SIUpfvOf5zXZYhVJv4fivKzhfXO93uLfJNB2reG gxfJNIAYN6dnGxfxCsI14nWjnzWwbtEXP6QoK8vZBZzyLkqD8QQjiBNuTy7rkc9hOLvxAZUIOkNy gVSRTdq.kMB_3nXe7e5z_DIDgeBt0G5e0euyfzK67LaDxudq3mRR9d5VJfZTSEu1OMLsqPerm9Is sr4_e2uhGUW8KpZ8Tx6tlygteXvURVEXvhrEp5FLd_XXkgLUTrLjsXOu2r6K__NpVYEqzOGy2JW5 20v3aOwxCEQmSVmE5rx8Vy6ku2YcnC7lLWRJmN2xxMsdWnhLoi1FRw.1WRiVb4PPd0nFKp_AiHZz ibpjReVDdSqNMMaiB2cCT1m1eqmUN187XkaNCwT88Yi5ZvzC_hcXcyj50T_4rX4YhooDrpEvj9r2 wsjjifUImOAEwsrw620KnSNqywcbApDjsylCKia84l6mVS1JH14fu6skOhuI1uuafzDLM8hNQzl7 V1MUpbS0O6GloBgaqnAve6nsHxeR3OXxGqmas7x21ogSL.A2xqUB8XVtrvVmR8nwGfJJoBp2QiuZ cLIQNYyP.oFAq0LUoatTEFFo0TDXZb4AZxt9WtXKuEA8HA67vIQCIWPvO.v7K8Opl.meZLql9Iwc Cx.UZ3C0O.vUtQZUlQ8shaEg_5FECS60nySotrQ_2c7zgY2ouGcuDJyUB08mHYCMMBX8RsMNXF98 mUqUxbIG6YSj_ZPnpR92Lap1iNxYhzs8f4JQfzLzS3Yb0cPS6qj53KEgc37YEjviZ7bPyFeiOr6l rH7ejsyDgHfnoBaw1h13X7BfZi0cGyrUfJcUleRtw8ztYR30f0EuyoIQK1F.Wc3sIGjqO_dOvEuf P5p_rRfIeRxHvt0fc0JwS_2iBkQNNwsGZ09gOT1VStdocF3_MNHu3JiFeaUF2IH5y0Ux8RsC.S3z ZGeg- Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.ne1.yahoo.com with HTTP; Fri, 1 Jan 2021 16:11:56 +0000 Date: Fri, 1 Jan 2021 16:11:52 +0000 (UTC) From: Filippo Moretti To: Mateusz Guzik , FreeBSD Current Message-ID: <680866542.6212528.1609517512906@mail.yahoo.com> In-Reply-To: <32309973.477796.1609513517947@mail.yahoo.com> References: <223516195.6185376.1609502236330.ref@mail.yahoo.com> <223516195.6185376.1609502236330@mail.yahoo.com> <32309973.477796.1609513517947@mail.yahoo.com> Subject: Re: Problem compiling git from ports MIME-Version: 1.0 X-Mailer: WebService/1.1.17278 YMailNorrin Mozilla/5.0 (X11; FreeBSD amd64; rv:84.0) Gecko/20100101 Firefox/84.0 X-Rspamd-Queue-Id: 4D6qlz1MSMz3Fr1 X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FREEMAIL_TO(0.00)[gmail.com,freebsd.org]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36646, ipnet:66.163.184.0/21, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[66.163.187.32:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; SPAMHAUS_ZRD(0.00)[66.163.187.32:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[66.163.187.32:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[66.163.187.32:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[current] Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 01 Jan 2021 16:12:00 -0000 =20 I run again portmaster and I have the same error as previously reportedFili= ppo On Friday, January 1, 2021, 4:05:18 PM GMT+1, Filippo Moretti wrote: =20 =20 Ufs=20 It exits with a different error: =3D=3D=3D> Installing contributed scripts /bin/mkdir -p /usr/ports/devel/git/work-default/stage/usr/local/share/git-c= ore/contrib cp -f -R /usr/ports/devel/git/work-default/git-2.30.0/contrib/* /usr/ports/= devel/git/work-default/stage/usr/local/share/git-core/contrib ln: /usr/ports/devel/git/work-default/stage/usr/local/etc/bash_completion.d= //git-completion.bash: File exists *** Error code 1 Stop. make[1]: stopped in /usr/ports/devel/git *** Error code 1 Stop. make: stopped in /usr/ports/devel/git Thank youFilippo On Friday, January 1, 2021, 3:52:33 PM GMT+1, Mateusz Guzik wrote: =20 =20 What filesystem is this? Does it work if you sysctl vfs.cache_fast_lookup=3D0 ? On 1/1/21, Filippo Moretti wrote: > I could not update git from 2.29 in my system > [root@STING /usr/ports/devel/git]# uname -a > FreeBSD STING 13.0-CURRENT FreeBSD 13.0-CURRENT #14 > main-c255423-gee938b20335: Wed Dec 30 10:41:00 CET 2020 > root@STING:/usr/obj/usr/src/amd64.amd64/sys/STING=C2=A0 amd64 > > > > > This is the error which can be duplicatedsincerelyFilippo > > > > [root@STING /usr/ports/devel/git]# gmake[3]: 'GIT-VERSION-FILE' is up to > date. > gmake[3]: Leaving directory '/usr/ports/devel/git/work-default/git-2.30.0= ' > sed -e '1s|#!.*/sh|#!/bin/sh|' git-subtree.sh >git-subtree > chmod +x git-subtree > install -d -m 755 > /usr/ports/devel/git/work-default/stage/usr/local/libexec/git-core > install -m 755 git-subtree > /usr/ports/devel/git/work-default/stage/usr/local/libexec/git-core > asciidoctor -b docbook -d manpage=C2=A0 \ >=C2=A0 =C2=A0 =C2=A0 =C2=A0 -agit_version=3D2.30.0 -I../../Documentation -= rasciidoctor-extensions > -alitdd=3D'--' git-subtree.txt > gmake[2]: asciidoctor: No such file or directory > gmake[2]: *** [Makefile:86: git-subtree.xml] Error 127 > gmake[2]: Leaving directory > '/usr/ports/devel/git/work-default/git-2.30.0/contrib/subtree' > *** Error code 2 > > Stop. > make[1]: stopped in /usr/ports/devel/git > *** Error code 1 > > Stop. > make: stopped in /usr/ports/devel/git > [root@STING /usr/ports/devel/git]# > > _______________________________________________ > 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= " > --=20 Mateusz Guzik _______________________________________________ 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" =20 From owner-freebsd-current@freebsd.org Fri Jan 1 16:24:51 2021 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 7CAEE4CC871 for ; Fri, 1 Jan 2021 16:24:51 +0000 (UTC) (envelope-from freebsd-current@dino.sk) Received: from mailhost.netlabit.sk (mailhost.netlabit.sk [84.245.65.72]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4D6r2p3Rk9z3GyP for ; Fri, 1 Jan 2021 16:24:50 +0000 (UTC) (envelope-from freebsd-current@dino.sk) Received: from zeta.dino.sk (fw3.dino.sk [84.245.95.254]) (AUTH: LOGIN milan) by mailhost.netlabit.sk with ESMTPA; Fri, 01 Jan 2021 17:24:42 +0100 id 00DD6320.5FEF4CCA.00004281 Date: Fri, 1 Jan 2021 17:24:41 +0100 From: Milan Obuch To: freebsd-current@freebsd.org Subject: Re: Problem compiling git from ports Message-ID: <20210101172441.4cf05744@zeta.dino.sk> In-Reply-To: <680866542.6212528.1609517512906@mail.yahoo.com> References: <223516195.6185376.1609502236330.ref@mail.yahoo.com> <223516195.6185376.1609502236330@mail.yahoo.com> <32309973.477796.1609513517947@mail.yahoo.com> <680866542.6212528.1609517512906@mail.yahoo.com> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; i386-portbld-freebsd11.4) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4D6r2p3Rk9z3GyP X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.30 / 15.00]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[84.245.65.72:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[dino.sk]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[84.245.65.72:from:127.0.2.255]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.997]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:5578, ipnet:84.245.64.0/18, country:SK]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 01 Jan 2021 16:24:51 -0000 On Fri, 1 Jan 2021 16:11:52 +0000 (UTC), Filippo Moretti wrote: > > I run again portmaster and I have the same error as previously > reportedFilippo On Friday, January 1, 2021, 4:05:18 PM GMT+1, Filippo > Moretti wrote: > Ufs > It exits with a different error: > ===> Installing contributed scripts > /bin/mkdir -p > /usr/ports/devel/git/work-default/stage/usr/local/share/git-core/contrib > cp -f -R /usr/ports/devel/git/work-default/git-2.30.0/contrib/* > /usr/ports/devel/git/work-default/stage/usr/local/share/git-core/contrib > ln: > /usr/ports/devel/git/work-default/stage/usr/local/etc/bash_completion.d//git-completion.bash: > File exists *** Error code 1 > > Stop. > make[1]: stopped in /usr/ports/devel/git > *** Error code 1 > > Stop. > make: stopped in /usr/ports/devel/git > I remember seeing this too. I worked around that using options: cat /var/db/ports/devel_git/options # This file is auto-generated by 'make config'. # Options for git-2.29.2 _OPTIONS_READ=git-2.29.2 _FILE_COMPLETE_OPTIONS_LIST=CONTRIB CURL CVS GITWEB GUI HTMLDOCS ICONV NLS P4 PERL SEND_EMAIL SUBTREE SVN PCRE PCRE2 OPTIONS_FILE_SET+=CONTRIB OPTIONS_FILE_SET+=CURL OPTIONS_FILE_SET+=CVS OPTIONS_FILE_UNSET+=GITWEB OPTIONS_FILE_UNSET+=GUI OPTIONS_FILE_UNSET+=HTMLDOCS OPTIONS_FILE_SET+=ICONV OPTIONS_FILE_UNSET+=NLS OPTIONS_FILE_SET+=P4 OPTIONS_FILE_SET+=PERL OPTIONS_FILE_SET+=SEND_EMAIL OPTIONS_FILE_UNSET+=SUBTREE OPTIONS_FILE_UNSET+=SVN OPTIONS_FILE_SET+=PCRE OPTIONS_FILE_UNSET+=PCRE2 Regards, Milan From owner-freebsd-current@freebsd.org Fri Jan 1 16:56:55 2021 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 953DA4CD7C9 for ; Fri, 1 Jan 2021 16:56:55 +0000 (UTC) (envelope-from rwmaillists@googlemail.com) Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D6rlp5tCTz3Kbf for ; Fri, 1 Jan 2021 16:56:54 +0000 (UTC) (envelope-from rwmaillists@googlemail.com) Received: by mail-wr1-x435.google.com with SMTP id w5so22281487wrm.11 for ; Fri, 01 Jan 2021 08:56:54 -0800 (PST) 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:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=ShMvuFWBOxLJI5yVygtGVqgdNjLEzjFbgL1ujj+uFvg=; b=OsuzA7rEDLQi2ntUJO8EJTsYnGmuo6fNmEqaFB/6/wDv21lz0wdMBerTI/5QIERfNM K6WQ6wYfYrnRSBXFUAd7SHHyS72B9vRWBuRslVzlc3/HHPfSoZ7rY23bXBGa/0xHVwdj 2aCqvQnHlmcxsTYJx3KOD/xONp9FhQU9wDynrMPEmqq8baRKuXRwm7A9iwUdvA8YeXFU z7fKWmjQ41XwPXbPcdoRoEZJ1wIi0s8vLF3/TXpEa8vPF3lBHL+PsXuLYuXEhSm5WWEF 31qBHwR1W5bCfe5m5cDLoWnefqngzaELvp4ZWQo6oYL+q6dVtm+5tZNvUsOUPNT1QDXA a9Bw== X-Gm-Message-State: AOAM533doy0CUGlDSdCawlBYZu9dpi5QH6VPMjHe+FzuHl98QpiHI62s qaVh0lxSZhBblIPPrQmtjN0xc7IrnwyB52rm X-Google-Smtp-Source: ABdhPJy0wxtAkdGB3KzNjfz4vWBKIaz4HLMSkJR03J70TNfgwkqRy3YT472B/YOE+ML+Duc9kr1IhQ== X-Received: by 2002:a5d:684b:: with SMTP id o11mr69625562wrw.157.1609520213157; Fri, 01 Jan 2021 08:56:53 -0800 (PST) Received: from gumby.homeunix.com ([90.195.197.185]) by smtp.gmail.com with ESMTPSA id e16sm82685806wra.94.2021.01.01.08.56.52 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 01 Jan 2021 08:56:52 -0800 (PST) Date: Fri, 1 Jan 2021 16:56:51 +0000 From: RW To: freebsd-current@freebsd.org Subject: Re: HEADS UP: FreeBSD src repo transitioning to git this weekend Message-ID: <20210101165651.7319af5a@gumby.homeunix.com> In-Reply-To: References: <5fdc0b90.1c69fb81.866eb.8c29SMTPIN_ADDED_MISSING@mx.google.com> <20201218175241.GA72552@spindle.one-eyed-alien.net> <20201218182820.1P0tK%steffen@sdaoden.eu> <20201223023242.GG31099@funkthat.com> <20201223162417.v7Ce6%steffen@sdaoden.eu> <20201229011939.GU31099@funkthat.com> <20201229210454.Lh4y_%steffen@sdaoden.eu> <20201230004620.GB31099@funkthat.com> <20201231193908.GC31099@funkthat.com> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.32; amd64-portbld-freebsd12.1) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4D6rlp5tCTz3Kbf X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[googlemail.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)[googlemail.com:+]; DMARC_POLICY_ALLOW(-0.50)[googlemail.com,quarantine]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RECEIVED_SPAMHAUS_PBL(0.00)[90.195.197.185:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[googlemail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a00:1450:4864:20::435:from]; DWL_DNSWL_NONE(0.00)[googlemail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[googlemail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[2a00:1450:4864:20::435:from:127.0.2.255]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::435:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 01 Jan 2021 16:56:55 -0000 On Thu, 31 Dec 2020 21:25:08 -0500 grarpamp wrote: > > Is there any reason to think [bittorrent] insecure? > > Cost under $50k of compute to break sha-1, AFAIK you cannot break SHA-1 in the sense of creating data that matches a specific hash. What you can do is create a collision between two blocks of data, varying both blocks in the process. This makes SHA-1 unsuitable for digital signatures. A *third-party* attacker cannot create a bogus torrent using a collision attack against SHA-1 because the attacker would need to match a specific hash value. What may be possible is that the creator of the legitimate torrent might create two torrents with the same hash, but this seems very contrived and not very useful. It has all sorts of problems as a way of delivering targeted malware. From owner-freebsd-current@freebsd.org Fri Jan 1 19:01:28 2021 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 4EA0A4D0DF0 for ; Fri, 1 Jan 2021 19:01:28 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D6vWW2qcXz3jCZ for ; Fri, 1 Jan 2021 19:01:27 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: by mail-wm1-x32f.google.com with SMTP id g25so5038465wmh.1 for ; Fri, 01 Jan 2021 11:01:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=oiE52gOaBv2YMENY2O1Ud8bJ7r2pqZs9PHkgR50/z7U=; b=B7MoOriztufyBfZ8bS/L1376C0eQmMErE5HBC7d16Y90d3eUa1d9StEiGPuC3nzlxs YcdspZ+q9PukVegjUbbyvPzPYVdclat8/LTiIMVEEf1e1oic+W+9F1oppqpmBLpFwiks 6NK9HuRwWt9DqbOAjHMWfnNB2O02H8nKRsE7B7nnMs9Q1F01/uCLk90vK+VW0sIWhgvL DVvmf6AHN2aqkBAr7oScPMnMSvYYsl3BhWN8MukRfARR2P1Qfuc39lIO6MzCPqVbMCex pfr+SwUvESd9fEi5dBkr5jwe3ZsUqc9Rj9qQgj86FOGkE2SMuiCr7mUMUixkuTBEroDt wIQw== X-Gm-Message-State: AOAM532SKrajxDd6xw3UkKXbyW2u50bKA0dC6xioDwvJNGtKsT+9UZuf 7r7j3VZs4PnM46sCwvr9/mPPYQGdFxOfpg== X-Google-Smtp-Source: ABdhPJwD2GIPHL1aKs3PHz04Ho3p/KU2zW1KxlcPUs2tJOlfgiXAGBQp193lyqti7KwxXmKNYaYZoA== X-Received: by 2002:a1c:b788:: with SMTP id h130mr16566589wmf.94.1609527685660; Fri, 01 Jan 2021 11:01:25 -0800 (PST) Received: from [192.168.1.11] (79-66-147-78.dynamic.dsl.as9105.com. [79.66.147.78]) by smtp.gmail.com with ESMTPSA id v1sm70947642wrr.48.2021.01.01.11.01.23 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 01 Jan 2021 11:01:24 -0800 (PST) To: freebsd-current@freebsd.org From: Graham Perrin Subject: etcupdate failed to build new tree Message-ID: Date: Fri, 1 Jan 2021 19:01:16 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-Rspamd-Queue-Id: 4D6vWW2qcXz3jCZ X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.80 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.80)[-0.795]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a00:1450:4864:20::32f:from]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; RECEIVED_SPAMHAUS_PBL(0.00)[79.66.147.78:received]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[2a00:1450:4864:20::32f:from:127.0.2.255]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::32f:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 01 Jan 2021 19:01:28 -0000 At what should have been the end of my first upgrade since the transition to git: cd /usr/src/freebsd-current && make installworld && etcupdate 𠄴– concluded with a successful installworld, then a few lines about scanning and skipping certificates, then: > Failed to build new tree. I see the manual page for etcupdate(8) but I'm not sure how to proceed. ---- I did try `mergemaster -p` and somehow (!) ended up with an empty `/etc/group` file. Dug myself out of that hole, I'll prefer to continue using etcupdate. From owner-freebsd-current@freebsd.org Fri Jan 1 19:24:53 2021 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 B09964D16E3 for ; Fri, 1 Jan 2021 19:24:53 +0000 (UTC) (envelope-from herbert@gojira.at) Received: from mail.bsd4all.net (mail.bsd4all.net [94.130.200.20]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail.bsd4all.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D6w2X4ppkz3kXZ for ; Fri, 1 Jan 2021 19:24:52 +0000 (UTC) (envelope-from herbert@gojira.at) Date: Fri, 01 Jan 2021 20:24:44 +0100 Message-ID: <87lfdctq83.wl-herbert@gojira.at> From: "Herbert J. Skuhra" To: freebsd-current@freebsd.org Subject: Re: etcupdate failed to build new tree In-Reply-To: References: User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/28.0 Mule/6.0 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4D6w2X4ppkz3kXZ X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.50 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gojira.at:s=mail202005]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:94.130.200.20]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[gojira.at]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[94.130.200.20:from:127.0.2.255]; DKIM_TRACE(0.00)[gojira.at:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MID_CONTAINS_FROM(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[94.130.200.20:from]; ASN(0.00)[asn:24940, ipnet:94.130.0.0/16, country:DE]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 01 Jan 2021 19:24:53 -0000 On Fri, 01 Jan 2021 20:01:16 +0100, Graham Perrin wrote: > = > At what should have been the end of my first upgrade since the > transition to git: > = > cd /usr/src/freebsd-current && make installworld && etcupdate > = > =F0=A0=84=B4=E2=80=93 concluded with a successful installworld, then = a few lines about > scanning and skipping certificates, then: > = > > Failed to build new tree. > = > I see the manual page for etcupdate(8) but I'm not sure how to procee= d. -s source Specify an alternate source tree to use when buildin= g or extracting a =E2=80=9Ccurrent=E2=80=9D tree. The= default source tree is /usr/src. = > ---- > = > I did try `mergemaster -p` and somehow (!) ended up with an empty > `/etc/group` file. Dug myself out of that hole, I'll prefer to > continue using etcupdate. -m /path/to/sources Specify the path to the directory where you want to do= the make(1). -- Herbert From owner-freebsd-current@freebsd.org Fri Jan 1 20:19:41 2021 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 518354D24F5 for ; Fri, 1 Jan 2021 20:19:41 +0000 (UTC) (envelope-from filippomore@yahoo.com) Received: from mailman.nyi.freebsd.org (unknown [127.0.1.3]) by mx1.freebsd.org (Postfix) with ESMTP id 4D6xFn0Q90z3mYr for ; Fri, 1 Jan 2021 20:19:41 +0000 (UTC) (envelope-from filippomore@yahoo.com) Received: by mailman.nyi.freebsd.org (Postfix) id 0C7EF4D279E; Fri, 1 Jan 2021 20:19:41 +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 0C40D4D279D for ; Fri, 1 Jan 2021 20:19:41 +0000 (UTC) (envelope-from filippomore@yahoo.com) Received: from sonic310-24.consmr.mail.ne1.yahoo.com (sonic310-24.consmr.mail.ne1.yahoo.com [66.163.186.205]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4D6xFm0Lq5z3mlG for ; Fri, 1 Jan 2021 20:19:39 +0000 (UTC) (envelope-from filippomore@yahoo.com) X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1609532377; bh=uWOWAV5sMhPwZMscGV4EyCqoieqtWRGZLxr/7Rj8HDU=; h=Date:From:To:Subject:From:Subject; b=P3coraDyV6inuYVxQAHck8Owak5Rv1qF/VBhjRzCDirClXdty6sy8KwKYJIrBZ3mSo4QC3I14/NZ55lDyeBegRPZYm6xPuGMS31boDewH9kHhyx1myjJ1Foz/GwFi6UVLaqt6QuFT6+o8o2ccIMh3fNuIBaQjbocEl1BZJ1pTyj2ukJkjyaAUP26wme4NVlwK+TC/l2jm/SrFNp+qb08mUpf8YvEOTnRT6sz4Jc1l5xG29xCCV6XC3+CMscRrkFl7d2RiYjcWqJ6R5JUszSG4loLv1KIo5aQn5BFX2K6RUw2e59h0dnOsIvxKlAyr7ukmoe+C2snA4Qm0im81rbCGQ== X-YMail-OSG: vNFNDQQVM1kYDW4Ney5uimZGXKdOzyaBZfnD_TFJj.jMjY5_eq_7CeKsSNVdArb o2IQbba16bQAjFYSOJBnTuQK6HUD7Sbebv3prdhROrClkWTMbBmaaMqpXG4qLSQh3OGQkbZ2iBMU moxoglFSzp8YSX2OKFXyyxrnGNxI9aDQ0DVWv8vhfasXZgF_EPDuWzaCs3VtkyHHYptRoaFZrA1u rwc0RlatWZYtoWtXPPuIh8ntcVLze9XEqkiz8HeDykLqFxRWlUMdAMjVGO0Op658mWx93LoV_e86 PvNm04acm3Ql69X4sNLiyUDSsgMwbw6F7rLEUMkzuSqtSY5lJgmq9cQn39p7GaSjwx5SYlsyFq6W JfLoh5O6qHNwtudYQp.ZB_wv9QqK43ENSHGO4ZxWnu7Qik.5SKv41GO5wRVO0T6QDnf6wTHhRxCs 9UGI9n15JmEfBKQha8inWgJpaK330ZkiWv7CafC3q5UeS2RIqXEneNjy3aZgvAbKqOrHag7Lb_Tr qGvrARkyA7I_WmwBLILwWGGSrZUgfFY3DrgohPwynKGAo3AFbzEGYRqLzTk8uyE7yWrtw_sA6DcI wnBkhipVkoT9Jnaf.Tsx7pZpM4zuQ7es8QxXUb4Ads5Rl8HQHXjSg2EH0OJe346gOZAdGeKpr45V 15_fsFNomF.59zXinom1bf47aM_sxAOD2n5rEUieZA6xkbf1sNzoDGe98aaqdhvbx3vDESBV4SpE CEVWa_ey1.R2vsQxEK.fTEziDvin1aS01Fl_YBA5v7RczMvIA4jG4HJsid.2Xv42B4SC08Om2ss0 0yHRoazScxgp5xlG4cMTD9BlHZPC2sQjB2atEcnEMZdpW80XkDnwD6c.bWV1ILH3xsOlnliJLDpq F0dwAVsmIabrYJytPa43n0GkT7wOL56kurFBkQMYszwiWm83TSRDnbVVt.QrBtoZomJ8TtruMppW FV_lYJM2tzuivOkTzSS9dBqgLORmg89pTRTMV6iSPMQIOO0Y47kbjvavscx8xpASk.Bl1TBdFbiL a0A1PL0JKBLciFLFjDzzoUM.UFHtqiwLj15FUJsCmvuvqYmrHA.wG5ZxdORlCCG2SgXl1INfIVNy 1qZWdjGMHTldytvZjQgDIsyD5_414_yNvpAYvDX3fE8Y7Q61DDuuHe1hSLD3Kcw7X392rRO2yHqD 0ame2RoptZdgh.KNzimXE7uXH5AdsiNLqDOMifcVYP2N0Q3_Qh324YYU9kb_EnAIEhQ581sOQy3W OlZd3k51he2YB_lC9QnBF96SCDMM4C4PIn.OUjTnL5Z1HRS6PV7wxzuvQRxkrPd01k4593nNG4m. yt4i.6DsIzWQTCh3tXcH81ExW4lIyuvmSgU1s9PdI9T_cuINlw2yQ.gXZpvObTfmWtyZ5cAvu7hY DbxqXJxDik0uoaE3m8D0Iv1G453B0BewzwjHof9.00X30SDbmhcDgBSgbsMGNDRJgNkMXHFB8Qga tyZkk78z2J86Gy4HxmhoxvK_YAFAzVcVWOC.oXkKEYkSUDX64PZZ0HJx14ErdPf87fhKekXbDpqQ QshO6jJjRabDKc3.RqPaqz._ZU0EoGvSEO2qhC.cKE0X8kliMA2E9OdL7Ec7eIBXrUe51is6lboA CYKMhJiJbqPHLxenQ1hq2rUXd_iiWr822abU_wZPR20lDMFjV.tgWMrkYeffQvdgNK7zTlV5wFsP Sioi3bS9zvu9TiwkNzrOxTHXk54iElKxOk8wx4IZvIg1wFjvA0ELEc18F7Lrd5ZeGzyx0qj7O4e4 GjNi7BdSMp1r8NX0V.34ydZrWghP1kGFeKwOsVl7P4.dCq7w1O5tDINhrpZLifXf3fwTOZZfQkHu iiQ3bDmxAh_fILb85vsFz_coSEd.0eBaMMeeETOo33XwWcGKbFRx9Tlr9V_EvfLCc9I4pIqmtN6d CdycMV1sMhhwhKTGjG4tQkTMd9EUpLJuG4Lo6oDMKfHXwun9dd5MiAtzYmz9XQHZRIUv8sBWifYv rKJ13h17TF1saQzQUuAKKOqxQgzddiZPv0iu__Tq86yY.JfXSWvQkNmKFOqLLsNHqm.8YrUuSKdi CaqEMuuo.ndA5Nb..V5Dga8L5znv6IX8jo8DJFLa1_7LltesrEBM8snc6fpRRMMA4mgoZ8VVKCal s68FX7p4dK.fis14P1Ifh_GZJcEmLSi3wC8vD8t8kE6eCJq_kTYo2LV4DcSoT1sT7YaRIYGlc_Fh R941MeABygjTdk0Uz12ISnzB__x.OgmVYEH62RMNlYB5UdsMPTyTmQw23KI.KGBiCK1ZsuwX10b8 UltGRh06nGxSaZ4iHHEOhGMKjUz1Mfkrt0Jsh7sWWXXghudZzEReGIu4WvJOX6bpObncu4Ma3Twy P7lyk9R.uH5zbP1drD6DcRz6wUM9PnaUs6JMEpOYw6T2VgAkXE5OZEgGHPV0jfgmjxTBAvkeRdp4 ymp0UZQCVs8Go Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.ne1.yahoo.com with HTTP; Fri, 1 Jan 2021 20:19:37 +0000 Date: Fri, 1 Jan 2021 20:19:37 +0000 (UTC) From: Filippo Moretti To: Milan Obuch , FreeBSD Current Message-ID: <1974288110.6258808.1609532377202@mail.yahoo.com> In-Reply-To: <20210101172441.4cf05744@zeta.dino.sk> References: <223516195.6185376.1609502236330.ref@mail.yahoo.com> <223516195.6185376.1609502236330@mail.yahoo.com> <32309973.477796.1609513517947@mail.yahoo.com> <680866542.6212528.1609517512906@mail.yahoo.com> <20210101172441.4cf05744@zeta.dino.sk> Subject: Re: Problem compiling git from ports MIME-Version: 1.0 X-Mailer: WebService/1.1.17278 YMailNorrin Mozilla/5.0 (X11; FreeBSD amd64; rv:84.0) Gecko/20100101 Firefox/84.0 X-Rspamd-Queue-Id: 4D6xFm0Lq5z3mlG X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; FREEMAIL_FROM(0.00)[yahoo.com]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36646, ipnet:66.163.184.0/21, country:US]; RBL_DBL_DONT_QUERY_IPS(0.00)[66.163.186.205:from]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; SPAMHAUS_ZRD(0.00)[66.163.186.205:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[66.163.186.205:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[66.163.186.205:from]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[current] Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 01 Jan 2021 20:19:41 -0000 =20 It worked thank youFilippo On Friday, January 1, 2021, 5:25:10 PM GMT+1, Milan Obuch wrote: =20 =20 On Fri, 1 Jan 2021 16:11:52 +0000 (UTC), Filippo Moretti wrote: >=C2=A0=20 > I run again portmaster and I have the same error as previously > reportedFilippo On Friday, January 1, 2021, 4:05:18 PM GMT+1, Filippo > Moretti wrote:=20 >=C2=A0 Ufs=20 > It exits with a different error: > =3D=3D=3D> Installing contributed scripts=C2=A0=20 > /bin/mkdir -p > /usr/ports/devel/git/work-default/stage/usr/local/share/git-core/contrib > cp -f -R /usr/ports/devel/git/work-default/git-2.30.0/contrib/* > /usr/ports/devel/git/work-default/stage/usr/local/share/git-core/contrib > ln: > /usr/ports/devel/git/work-default/stage/usr/local/etc/bash_completion.d//= git-completion.bash: > File exists *** Error code 1 >=20 > Stop. > make[1]: stopped in /usr/ports/devel/git > *** Error code 1 >=20 > Stop. > make: stopped in /usr/ports/devel/git >=20 I remember seeing this too. I worked around that using options: cat /var/db/ports/devel_git/options=20 # This file is auto-generated by 'make config'. # Options for git-2.29.2 _OPTIONS_READ=3Dgit-2.29.2 _FILE_COMPLETE_OPTIONS_LIST=3DCONTRIB CURL CVS GITWEB GUI HTMLDOCS ICONV NL= S P4 PERL SEND_EMAIL SUBTREE SVN PCRE PCRE2 OPTIONS_FILE_SET+=3DCONTRIB OPTIONS_FILE_SET+=3DCURL OPTIONS_FILE_SET+=3DCVS OPTIONS_FILE_UNSET+=3DGITWEB OPTIONS_FILE_UNSET+=3DGUI OPTIONS_FILE_UNSET+=3DHTMLDOCS OPTIONS_FILE_SET+=3DICONV OPTIONS_FILE_UNSET+=3DNLS OPTIONS_FILE_SET+=3DP4 OPTIONS_FILE_SET+=3DPERL OPTIONS_FILE_SET+=3DSEND_EMAIL OPTIONS_FILE_UNSET+=3DSUBTREE OPTIONS_FILE_UNSET+=3DSVN OPTIONS_FILE_SET+=3DPCRE OPTIONS_FILE_UNSET+=3DPCRE2 Regards, Milan _______________________________________________ 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" =20 From owner-freebsd-current@freebsd.org Fri Jan 1 20:25:13 2021 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 82F004D2AF1 for ; Fri, 1 Jan 2021 20:25:13 +0000 (UTC) (envelope-from news@mips.inka.de) Received: from mail.inka.de (mail.inka.de [IPv6:2a04:c9c7:0:1073:217:a4ff:fe3b:e77c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4D6xN84149z3nG0 for ; Fri, 1 Jan 2021 20:25:12 +0000 (UTC) (envelope-from news@mips.inka.de) Received: from mips.inka.de (news@[127.0.0.1]) by mail.inka.de with uucp (rmailwrap 0.5) id 1kvQyu-000Txu-CP; Fri, 01 Jan 2021 21:25:04 +0100 Received: from lorvorc.mips.inka.de (localhost [127.0.0.1]) by lorvorc.mips.inka.de (8.16.1/8.16.1) with ESMTP id 101KOKhF028374 for ; Fri, 1 Jan 2021 21:24:20 +0100 (CET) (envelope-from news@lorvorc.mips.inka.de) Received: (from news@localhost) by lorvorc.mips.inka.de (8.16.1/8.16.1/Submit) id 101KOKdJ028373 for freebsd-current@freebsd.org; Fri, 1 Jan 2021 21:24:20 +0100 (CET) (envelope-from news) To: freebsd-current@freebsd.org From: Christian Weisgerber Newsgroups: list.freebsd.current Subject: Re: HEADS UP: FreeBSD src repo transitioning to git this weekend Date: Fri, 1 Jan 2021 20:24:20 -0000 (UTC) Message-ID: References: <20201218175241.GA72552@spindle.one-eyed-alien.net> <20201218182820.1P0tK%steffen@sdaoden.eu> <20201223023242.GG31099@funkthat.com> <20201223162417.v7Ce6%steffen@sdaoden.eu> <20201229011939.GU31099@funkthat.com> <20201229210454.Lh4y_%steffen@sdaoden.eu> <20201230004620.GB31099@funkthat.com> <20201231193908.GC31099@funkthat.com> <20210101140857.x3hbci6c4nwi7gl7@mutt-hbsd> User-Agent: slrn/1.0.3 (FreeBSD) X-Rspamd-Queue-Id: 4D6xN84149z3nG0 X-Spamd-Bar: - X-Spamd-Result: default: False [-1.78 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; FREEFALL_USER(0.00)[news]; FROM_HAS_DN(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a04:c9c7:0:1073:217:a4ff:fe3b:e77c:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[2a04:c9c7:0:1073:217:a4ff:fe3b:e77c:from:127.0.2.255]; RCVD_COUNT_THREE(0.00)[3]; DMARC_NA(0.00)[inka.de]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-0.98)[-0.976]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[naddy@mips.inka.de,news@mips.inka.de]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:202113, ipnet:2a04:c9c7::/32, country:DE]; FROM_NEQ_ENVFROM(0.00)[naddy@mips.inka.de,news@mips.inka.de]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 01 Jan 2021 20:25:13 -0000 On 2021-01-01, Shawn Webb wrote: > This is why I asked FreeBSD to provide anonymous read-only ssh:// > support for git. I'm very grateful they support it. > > One thing that I need to do with the HardenedBSD infrastructure is > publish on our site the ssh pubkeys of the server (both RSA and > ed25519). I plan to do that sometime this coming week. I wonder if it > would be a good idea for FreeBSD to do the same The draft FreeBSD Git docs have the SSH fingerprints of the Git servers. https://github.com/bsdimp/freebsd-git-docs/blob/main/URLs.md Here's one from my own ~/.ssh/known_hosts: SHA256:y1ljKrKMD3lDObRUG3xJ9gXwEIuqnh306tSyFd1tuZE git.freebsd.org (ED25519) -- Christian "naddy" Weisgerber naddy@mips.inka.de From owner-freebsd-current@freebsd.org Fri Jan 1 20:29:49 2021 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 21E774D3094 for ; Fri, 1 Jan 2021 20:29:49 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D6xTS3Jk6z3nVr for ; Fri, 1 Jan 2021 20:29:48 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: by mail-wr1-x431.google.com with SMTP id r7so22679867wrc.5 for ; Fri, 01 Jan 2021 12:29:48 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=QsfxLVI0HHq39hig4pLOfQM1bNMqr/1fMCTsub6eZIA=; b=Z2ENhqy32+4fqN+IjQazZG5B4ogcGEGNvpuvOCmIj/Hu1pcG2IfpMn3RJjGU/gUDNM prWvcgrHqLfjLe4E9uDcYJp0eqXD7xcdgIaCAcFAgDgvlDV8eLK/7VQ5AkCh/o7QCw4P I/NgyCkxrUWrOQSNW87/u+uq7AQSrdOfKsTxhmwNuFs8YZxx6EdX2wokOn7dnAG2VrPd wps+jglf34e9xlw0K0tqswiB9GiApMwzADnuoR3YMDoyuPuGDvkUVd1PQZRyrytBg2HB Bn2DhY21NWWrAFVgdpC+Xb25wkk2wCZWxGIM8GyeusF/drCsSyf61VkIbPmZcbl+Bu5u y6vQ== X-Gm-Message-State: AOAM530qbxljHMaLa/Qhe9np824OK+Za7IW1VnKqvsQiXSGtqFO7g2a3 ZRra9YOntc57GzFIatrfIFVWY5Bm2krXoA== X-Google-Smtp-Source: ABdhPJzAOAhsrVox1x1Mhdqr4lUtvV3X27ujTtp2EINFIqeVBu8Q/Ht8xfRUeIYIYVKeBEOAlIE/mg== X-Received: by 2002:adf:c642:: with SMTP id u2mr59202214wrg.243.1609532986337; Fri, 01 Jan 2021 12:29:46 -0800 (PST) Received: from [192.168.1.11] (79-66-147-78.dynamic.dsl.as9105.com. [79.66.147.78]) by smtp.gmail.com with ESMTPSA id c20sm18400259wmb.38.2021.01.01.12.29.45 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 01 Jan 2021 12:29:45 -0800 (PST) Subject: mergemaster option -m (was: etcupdate failed to build new tree) To: freebsd-current@freebsd.org References: <87lfdctq83.wl-herbert@gojira.at> From: Graham Perrin Message-ID: Date: Fri, 1 Jan 2021 20:29:45 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <87lfdctq83.wl-herbert@gojira.at> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-Rspamd-Queue-Id: 4D6xTS3Jk6z3nVr X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RECEIVED_SPAMHAUS_PBL(0.00)[79.66.147.78:received]; FROM_EQ_ENVFROM(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a00:1450:4864:20::431:from]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[2a00:1450:4864:20::431:from:127.0.2.255]; MIME_TRACE(0.00)[0:+]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::431:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 01 Jan 2021 20:29:49 -0000 On 01/01/2021 19:24, Herbert J. Skuhra wrote: > On Fri, 01 Jan 2021 20:01:16 +0100, Graham Perrin wrote: > >> … >> >> I did try `mergemaster -p` and somehow (!) ended up with an empty >> `/etc/group` file. Dug myself out of that hole, I'll prefer to >> continue using etcupdate. > -m /path/to/sources > Specify the path to the directory where you want to do the > make(1). Thank you, what path would you suggest? (Given the previous weirdness, I want to make no guesses here.) From owner-freebsd-current@freebsd.org Fri Jan 1 20:40:16 2021 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 894F04D30E9 for ; Fri, 1 Jan 2021 20:40:16 +0000 (UTC) (envelope-from me+freebsd@igalic.co) Received: from mail-40136.protonmail.ch (mail-40136.protonmail.ch [185.70.40.136]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "protonmail.com", Issuer "SwissSign Server Gold CA 2014 - G22" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D6xjV1kpdz3pBf for ; Fri, 1 Jan 2021 20:40:14 +0000 (UTC) (envelope-from me+freebsd@igalic.co) Date: Fri, 01 Jan 2021 20:40:07 +0000 To: Allan Jude From: =?utf-8?Q?Mina_Gali=C4=87?= Cc: FreeBSD Current Reply-To: =?utf-8?Q?Mina_Gali=C4=87?= Subject: Re: Enabling AESNI by default Message-ID: In-Reply-To: <5d56280e-a8dd-b28d-7039-f8fe0bc0cd6f@freebsd.org> References: <5d56280e-a8dd-b28d-7039-f8fe0bc0cd6f@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=10.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF shortcircuit=no autolearn=disabled version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mailout.protonmail.ch X-Rspamd-Queue-Id: 4D6xjV1kpdz3pBf X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.79 / 15.00]; HAS_REPLYTO(0.00)[me+freebsd@igalic.co]; R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[igalic.co:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[185.70.40.136:from]; R_MIXED_CHARSET(0.71)[subject]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH]; TAGGED_FROM(0.00)[freebsd]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[igalic.co:s=protonmail2]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[me]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[igalic.co]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SPAMHAUS_ZRD(0.00)[185.70.40.136:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[185.70.40.136:from]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 01 Jan 2021 20:40:16 -0000 On Thursday, December 31st, 2020 at 20:51, Allan Jude wrote: > We've had the AESNI module for quite a few years now, and it has not caus= ed any problems. > > I am wondering if there are any objections to including it in GENERIC, so= that users get the benefit without having to have the "tribal knowledge" t= hat 'to accelerate kernel crypto (GELI, ZFS, IPSEC, etc), you need to load = aesni.ko' This tribal knowledge is encoded in bsdinstall when you setup encryption on= zfs: https://cgit.freebsd.org/src/tree/usr.sbin/bsdinstall/scripts/zfsboot#n1207 Mina From owner-freebsd-current@freebsd.org Fri Jan 1 22:07:06 2021 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 6FCBA4D5AA8 for ; Fri, 1 Jan 2021 22:07:06 +0000 (UTC) (envelope-from herbert@gojira.at) Received: from mail.bsd4all.net (mail.bsd4all.net [IPv6:2a01:4f8:13b:240c::25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail.bsd4all.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D6zdj2p0Bz3vfZ for ; Fri, 1 Jan 2021 22:07:04 +0000 (UTC) (envelope-from herbert@gojira.at) Date: Fri, 01 Jan 2021 23:06:56 +0100 Message-ID: <87k0swtipr.wl-herbert@gojira.at> From: "Herbert J. Skuhra" To: freebsd-current@freebsd.org Subject: Re: mergemaster option -m (was: etcupdate failed to build new tree) In-Reply-To: References: <87lfdctq83.wl-herbert@gojira.at> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/28.0 Mule/6.0 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=ISO-2022-JP X-Rspamd-Queue-Id: 4D6zdj2p0Bz3vfZ X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.38 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gojira.at:s=mail202005]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a01:4f8:13b:240c::25]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[gojira.at]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[2a01:4f8:13b:240c::25:from:127.0.2.255]; DKIM_TRACE(0.00)[gojira.at:+]; NEURAL_HAM_SHORT(-0.88)[-0.875]; MID_CONTAINS_FROM(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a01:4f8:13b:240c::25:from]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/29, country:DE]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 01 Jan 2021 22:07:06 -0000 On Fri, 01 Jan 2021 21:29:45 +0100, Graham Perrin wrote: > > On 01/01/2021 19:24, Herbert J. Skuhra wrote: > > > On Fri, 01 Jan 2021 20:01:16 +0100, Graham Perrin wrote: > > > >> $B!D(B > >> > >> I did try `mergemaster -p` and somehow (!) ended up with an empty > >> `/etc/group` file. Dug myself out of that hole, I'll prefer to > >> continue using etcupdate. > > -m /path/to/sources > > Specify the path to the directory where you want to do the > > make(1). > > > Thank you, what path would you suggest? > > (Given the previous weirdness, I want to make no guesses here.) 1. Your SOURCEDIR is /usr/src/freebsd-current and not /usr/src. Unlike etcupdate mergemaster checks for Makefile1.inc in the working directory and asks to set SOURCEDIR accordingly: *** /usr/src was not found. Found Makefile.inc1 in the current directory. Would you like to set SOURCEDIR to /mnt2/src? [no and exit] Did you see this prompt? 2. Do you have (old) files (e.g. Makefile.inc1) or directories (e.g. etc) in /usr/src? Is this problem reproducible? Does it work if use -m switch, e.g: 'mergemaster -m .' or 'mergemaster -m /usr/src/freebsd-current'? -- Herbert From owner-freebsd-current@freebsd.org Fri Jan 1 22:58:04 2021 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 9B84F4D6DBC for ; Fri, 1 Jan 2021 22:58:04 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qv1-xf34.google.com (mail-qv1-xf34.google.com [IPv6:2607:f8b0:4864:20::f34]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature 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 4D70mW30Klz4T90 for ; Fri, 1 Jan 2021 22:58:03 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qv1-xf34.google.com with SMTP id j18so10423256qvu.3 for ; Fri, 01 Jan 2021 14:58:03 -0800 (PST) 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=FO5FbhP/0LOi7xVnWgRQYY6MrjR1uPMokw7wpjbLjUw=; b=LKLxq+ZrxXnX+kLPGIMMD3ruFGu8Y/QBqN4cAqUmVsgQpDX4WJ78kPsrj39zATFO4d Lg21gRFGVHEdZocxnXoTsa+HHfDRCTZ7nh9lvSpeQXSbJJcwyW5v6w3ggUJU+7qpeq1G yEE+iHiGnIxKzQR+eZKDDdhtLhyytMOBRjFVxNc1z2saaPyI65MVuJ0WU4JKlfj3KmWZ XBJ2oyi8hri+MRxlH5hbU+wIu9FzGR613NIPftNwfqokDbVSnpbf7kLsMWUY6LTt6Stt oVbXsx0f1AtmJEnNEkuAqYFT1UaCyxaJuMgoZFyVKu3YOKSq7KTtRAB1SOvpSd8QEYva ni0g== X-Gm-Message-State: AOAM533mbI/kst/wswfC99gGp3woDSoo8LYptu6YUU9DAuz9oslowk0X SrMk9W5xXMECkIPKLeOewNuZtsDURJdmZ9fhg9y/jQ== X-Google-Smtp-Source: ABdhPJzPtbj7rGpl8W9hkB53MSNIYt2j0ZW9qzLcuXQFD4w6CK3j0blQT3mhclEm8CaxS1nT/C+Zjru1Ov8JNFW0e2o= X-Received: by 2002:a05:6214:16cb:: with SMTP id d11mr66567539qvz.62.1609541882299; Fri, 01 Jan 2021 14:58:02 -0800 (PST) MIME-Version: 1.0 References: <5d56280e-a8dd-b28d-7039-f8fe0bc0cd6f@freebsd.org> In-Reply-To: From: Warner Losh Date: Fri, 1 Jan 2021 15:57:50 -0700 Message-ID: Subject: Re: Enabling AESNI by default To: =?UTF-8?Q?Mina_Gali=C4=87?= Cc: Allan Jude , FreeBSD Current X-Rspamd-Queue-Id: 4D70mW30Klz4T90 X-Spamd-Bar: -- X-Spamd-Result: default: False [-3.00 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; TAGGED_RCPT(0.00)[freebsd]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; SPAMHAUS_ZRD(0.00)[2607:f8b0:4864:20::f34:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::f34: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:~]; RBL_DBL_DONT_QUERY_IPS(0.00)[2607:f8b0:4864:20::f34:from]; 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]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 01 Jan 2021 22:58:04 -0000 On Fri, Jan 1, 2021, 1:40 PM Mina Gali=C4=87 wrote: > On Thursday, December 31st, 2020 at 20:51, Allan Jude < > allanjude@freebsd.org> wrote: > > > We've had the AESNI module for quite a few years now, and it has not > caused any problems. > > > > I am wondering if there are any objections to including it in GENERIC, > so that users get the benefit without having to have the "tribal knowledg= e" > that 'to accelerate kernel crypto (GELI, ZFS, IPSEC, etc), you need to lo= ad > aesni.ko' > > This tribal knowledge is encoded in bsdinstall when you setup encryption > on zfs: > > https://cgit.freebsd.org/src/tree/usr.sbin/bsdinstall/scripts/zfsboot#n12= 07 Even so, adding to GENERIC is fine. Warner > > Mina > _______________________________________________ > 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 Jan 1 23:00:50 2021 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 771964D713F for ; Fri, 1 Jan 2021 23:00:50 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670084.outbound.protection.outlook.com [40.107.67.84]) (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 4D70qj12V0z4Tc5; Fri, 1 Jan 2021 23:00:48 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=J3uxzkU+5w7DkzmsXvpGsQRjHI1KFFbIdTjiSduRcKI04ftyKRaXmyt9ffV8D7pVzd4ccIiRzGvJm+xCQZH7qX8CY6VqIhTJlMgr4eQ0uGTq1ot87eRZf9v+U6KgG/7sLuztExus+7/D1XrvTvjVOfavStKS+cINrOQd7qWHt6eLFGTqR29q4ZszL7GOp9mfpsyAwJRF5Ph3vUGJXqdi4E+u22O7GwqgrMdhnN2MecXplgYWt2KsjXogIZtrITZp8p2wE1Hh2Fc43R3a6z10x8Y3d2HJVBjs0neCXUgQSOQFpH2yBm41joA9Myj5VnLNciuQGfibFq4R2i5i9qsobw== 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=jfAXfRgb3+jrbxfvKWaSqgWdT2nr1qX8x6p4VAUx7SA=; b=eBsq5uOwM/KQW/bcri68ATpIIpxf7ciyzOsL71IHtYhenP2WJXqm5tuwhKet1zMxLy7WVE/69D325v3oH3RIoK3LeT0C7vyqCOxYNHePxI7a5G+J4YB86oqFay15Tyaz+Ox1n4q0EHqDmPpQqoAV/yreG9BSCMCtYqcKnloYv0REX4qf/Bi0NHe+Slm7MMCkBX/oH3MfpY2Way68CjIJpT2i/d6dlNDy8y/62lUzve9UJrTsCRkbe/S6K9Q/5a6y/Tl8/cQ3hAhcYdZ3ACMnrt6JpXS3KIjK5JNAXl0N7Xcqzz3yiotG2r7xKdEs+y+a88abUHcS71i2gJGIUZmMXw== 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 YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:19::29) by YQBPR0101MB1364.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:a::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3721.19; Fri, 1 Jan 2021 23:00:47 +0000 Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::3d86:c7f9:bc4c:40c0]) by YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::3d86:c7f9:bc4c:40c0%6]) with mapi id 15.20.3721.023; Fri, 1 Jan 2021 23:00:47 +0000 From: Rick Macklem To: Konstantin Belousov CC: "freebsd-current@freebsd.org" , Alan Somers , Kirk McKusick , Mark Johnston Subject: Re: r367672 broke the NFS server Thread-Topic: r367672 broke the NFS server Thread-Index: AQHW3k3ynlL3lGhXRkC37zjbBa1PUKoPmNaAgAA7NVaAABFYAIAAwg6JgABvToCAALma1IABlq32 Date: Fri, 1 Jan 2021 23:00:47 +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: 0aa77b31-6902-446c-9ee7-08d8aea913a4 x-ms-traffictypediagnostic: YQBPR0101MB1364: 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: Gt7/DHbwqYjq7h/Bgv9OjCoteoVxvR1ocx+rEEwiNvoDSFqzYJqtDs2RNJTNWevd7X4lupHkEClovPj3ukQrHyMOEqM+S5L0k2YoSNCujX0eOHxuuLc2cyhZrl8M7rVvfAZwuZCBK8hvRB6XdbgsILskzpOJQyK3/gBfCDaSz88E8pLmRCd/s+i3Tfsug5Tk351Ld5cHAoBUz4GcAWMEpzmJKEidekV/6KdASStEmxKCblB4brfU+wAsuzGA2lJUWkxHF60ydMAcVOXk1+HXBNr2Pe/nL7+kbJigxRpCXI7irtxquU6pP4JhlH0ewBqj5dhyk3APWQSEp4IwxPhQYuOvBQ/KQ7fZDkOaLHRo1BnAbyYDgR0xvfATtnKZekJvFvyxhF+9F7xmXHYcvaArQUb9xFfXX2C1TFRIC5FiUC2DJR2tV+B02wB5/TfeNk36O60U8SUi1ZaIzxbc5EhKwg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(366004)(39850400004)(136003)(346002)(376002)(396003)(26005)(186003)(71200400001)(4326008)(33656002)(478600001)(55016002)(6916009)(2906002)(9686003)(66556008)(66476007)(52536014)(66446008)(53546011)(6506007)(5660300002)(8936002)(64756008)(54906003)(966005)(83380400001)(91956017)(8676002)(86362001)(76116006)(7696005)(316002)(786003)(66946007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?WVWZ6dY/uR4v95iptSTCvzEg9hcnwsiDkhWeQa819AvII/h+bJhgAB/RxPKF?= =?us-ascii?Q?8B2h+uJNQFZLcbH8LrKxFjkQJfFPFzZYv7IzRpD0o9XC8DuSwclRDwcoMDnj?= =?us-ascii?Q?ir6Gx2OD9hdXGIvCjg9nBsu18FLe5xvmPP6o9OQowLgbpHm1iD9kpTbHsAU2?= =?us-ascii?Q?JmJuYy41OzAoD5bYT0zZMRwvkolpkpON0TZH1/ssaDAZKMWxdsTCURG8SOf0?= =?us-ascii?Q?S5xpcv1sXV+RePoTPBoQNT5M7JmNphYTzaQxsX2tFg/WqCt6ahfnfi8MRJEc?= =?us-ascii?Q?JC/aDNReMM1aFvFQGQfl1KghzxFXngX6trWzgC/3RD3VIPXR7/ypeDgEe4t6?= =?us-ascii?Q?CWX59teLQX7Lg/Al2ESPdZGsiSmRmHEe61gq8y5GvbrNSCePrCeeLa3kNU3N?= =?us-ascii?Q?1WJJPMgOHVqF28eF1SSXNb1MkDdH2vJFrdxlxHfl5Cf9mkgd7I48bZ9XnyG9?= =?us-ascii?Q?iKK9lgQlMlQXUamLHskeFqzMbYUB58T4c+P38nYHysFaXaR9Oelc6tLuHIwE?= =?us-ascii?Q?P5DZMMbFBQiZZDU0A2uDoUJvdK6/9Fv5Pz8UNctoPOch+Hr4kXYVOQS61Nd6?= =?us-ascii?Q?QOb8mSuGg5P38zGng7/q/TdpgnRdUonXoKo0HwC7Y/m1j/cR8jfginY06XFD?= =?us-ascii?Q?OAKXN3j98Js4JY6KK3cxaxGM/1g543ubxrj0lU1zF3zsznmuLjj/ZXBpBfzb?= =?us-ascii?Q?6SF/ZFSR4dU/95OKpdlPoKaHxlpnToPcOPfzh04Z+vPdbLtyuj+4urC8uVp4?= =?us-ascii?Q?bYJ9c1iXgRol9b3PidZWxaTbN8p3/SMB0IwQICsn/eqjiTh/U3AMHQRnLsqW?= =?us-ascii?Q?Dv+LrspH593yiIbIIz+rV5hAW2yu5KrllH0TRPLynqei55fy4i9AHvZTiSxB?= =?us-ascii?Q?tUNGwKHe2QRk/qaNmN9yeTWU0/lz8wU44yBeY/fBmVz3AL8uRqDX9xUFlhrO?= =?us-ascii?Q?yZbiPjcMRVL/Nnb4BWvqM+FZ3oPxbkWqdsmucjZI7GM=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 0aa77b31-6902-446c-9ee7-08d8aea913a4 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Jan 2021 23:00:47.4667 (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: aY1BezYk3SkvqmjKNOBbfrw60bHEMSMyslKIKMBpHLk2wI95qa27YeNPpR0bPpHjCPd1dA+y2SQvs1FfGaIbvA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQBPR0101MB1364 X-Rspamd-Queue-Id: 4D70qj12V0z4Tc5 X-Spamd-Bar: ------ X-Spamd-Result: default: False [-6.00 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16:c]; RCPT_COUNT_FIVE(0.00)[5]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[uoguelph.ca:+]; DMARC_POLICY_ALLOW(-0.50)[uoguelph.ca,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[40.107.67.84:from]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector1]; FREEFALL_USER(0.00)[rmacklem]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim]; SPAMHAUS_ZRD(0.00)[40.107.67.84:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[40.107.67.84:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.67.84:from]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 01 Jan 2021 23:00:50 -0000 The patches that I believe fix this are now committed to head. Have a good 2021, rick ________________________________________ From: owner-freebsd-current@freebsd.org = on behalf of Rick Macklem Sent: Thursday, December 31, 2020 5:56 PM To: Konstantin Belousov Cc: freebsd-current@freebsd.org; Alan Somers; Kirk McKusick; Mark Johnston Subject: Re: r367672 broke the NFS server Just fyi, I have put a patch up on phabricator as D27875 that seems to fix the problem for all NFS client mounts except NFSv4.0. NFSv4.0 will require an additional fix so that the "seqid" is properly maintained during redos of the Open caused by the ERELOOKUP redo. If anyone is running a recent head kernel on a system that NFS exports UFS file systems, please test this patch. Peter, can you test this? If acquiring the patch from phabricator is awkward, just email and I will send you a copy of the patch. Thanks, rick ps: If possible, I'd like to commit this patch in a couple of days, given the FreeBSD release schedule. ________________________________________ From: owner-freebsd-current@freebsd.org = on behalf of Konstantin Belousov Sent: Thursday, December 31, 2020 6:40 AM To: Rick Macklem Cc: freebsd-current@freebsd.org; Alan Somers; Kirk McKusick; Mark Johnston Subject: Re: r367672 broke the NFS server CAUTION: This email originated from outside of the University of Guelph. Do= not click links or open attachments unless you recognize the sender and kn= ow the content is safe. If in doubt, forward suspicious emails to IThelp@uo= guelph.ca On Thu, Dec 31, 2020 at 05:16:27AM +0000, Rick Macklem wrote: > Rick Macklem wrote: > >Kostik wrote: > > > > > >Idea of the change is to restart the syscall at top level. So for NFS > > >server the right approach is to not send a response and also to not > > >free the request mbuf chain, but to restart processing. > > Yes. I took a look and I think restarting the operation by rolling the > > working position in the mbuf lists back and redoing the operation > > is feasible and easier than fixing the individual operations. > > > > For NFSv4, you cannot redo the entire compound, since non-idempotent > > operations like exclusive open may have already been completed. > > However, rolling back to the beginning of the operation should be > > doable. > Turned out to be quite easy. I'll stick a patch up on phabricator > tomorrow, after I do a little more testing. > NFSv4.0 is still broken, because it screws up the seqid, but I can > fix that separately. > > I do see the code looping about 2-3 times before it gets a successful > ufs_create(). Does that sound reasonable? In the simple case, it could be described as is: ERELOOKUP is returned if the parent directory cannot be locked sleep-less, and we have to drop the lock for opened vnode to sleep on it. More elaborate (but still not precise) description is that parent directory might also need to be synced, in which case its parent might need to be locked, and so on recursively. Slightly reformulating, I expect that ERELOOKUPs come out in case several threads create files in the same directory. > Here's some debug printfs for the test run of 4 concurrent compiles. > (proc=3D8 is create and proc=3D12 is remove. Each line is a ERELOOKUP > retry. This is for the 4 threads, but I had the thread tid in another pr= intf > and it showed 2-3 attempts for the same thread. They should be serialize= d > by the exclusive lock on the directory vnode.) I cannot make any conclusion from the output and its description. Are there opens that do not result in ERELOOKUP, i.e. does the op eventually succeed ? What is the ratio of ERELOOKUP vs. success ? Also note that any VOP that modify the volume' metadata might result in ERELOOKUP. > tryag3 stat=3D0 proc=3D8 > tryag3 stat=3D0 proc=3D8 _______________________________________________ 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" _______________________________________________ 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 Jan 1 23:20:37 2021 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 9DBD14D7C08 for ; Fri, 1 Jan 2021 23:20:37 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "ultimatedns.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D71GY1Tcwz4VL8 for ; Fri, 1 Jan 2021 23:20:36 +0000 (UTC) (envelope-from bsd-lists@bsdforge.com) Received: from ultimatedns.net (localhost [127.0.0.1]) by udns.ultimatedns.net (8.16.1/8.16.1) with ESMTP id 101NKT74094754; Fri, 1 Jan 2021 15:20:35 -0800 (PST) (envelope-from bsd-lists@bsdforge.com) MIME-Version: 1.0 Date: Fri, 01 Jan 2021 15:20:29 -0800 From: Chris To: Graham Perrin Cc: freebsd-current@freebsd.org Subject: Re: etcupdate failed to build new tree In-Reply-To: References: User-Agent: UDNSMS/17.0 Message-ID: <808d450f0d475b8bf9c46021d33105c6@bsdforge.com> X-Sender: bsd-lists@bsdforge.com Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4D71GY1Tcwz4VL8 X-Spamd-Bar: / X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 01 Jan 2021 23:20:37 -0000 On 2021-01-01 11:01, Graham Perrin wrote: > At what should have been the end of my first upgrade since the transition to > git: > > cd /usr/src/freebsd-current && make installworld && etcupdate > > 𠄴– concluded with a successful installworld, then a few lines about scanning > and > skipping certificates, then: > >> Failed to build new tree. > > I see the manual page for etcupdate(8) but I'm not sure how to proceed. > > ---- > > I did try `mergemaster -p` and somehow (!) ended up with an empty > `/etc/group` > file. Dug myself out of that hole, I'll prefer to continue using etcupdate. For years now I have always initiated a simple failsafe # cp -Rp /etc /eetc prior to (build|install) (world|kernel) because you just never know. ;-) Happy 20201! --Chris From owner-freebsd-current@freebsd.org Sat Jan 2 00:37:26 2021 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 599C14B9783 for ; Sat, 2 Jan 2021 00:37:26 +0000 (UTC) (envelope-from lwhsu@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D72zB1v6Nz4Zqg for ; Sat, 2 Jan 2021 00:37:26 +0000 (UTC) (envelope-from lwhsu@freebsd.org) Received: from mail-yb1-f181.google.com (mail-yb1-f181.google.com [209.85.219.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) (Authenticated sender: lwhsu/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 2DC502FCB3 for ; Sat, 2 Jan 2021 00:37:26 +0000 (UTC) (envelope-from lwhsu@freebsd.org) Received: by mail-yb1-f181.google.com with SMTP id d37so20640168ybi.4 for ; Fri, 01 Jan 2021 16:37:26 -0800 (PST) X-Gm-Message-State: AOAM532rJAye+kpHEnhP5RXopwg54X8pCKIbaSX1TYxAl8ZfqII5zWlF 5J9mpTNRJVXuu4CzT5KIr53fHp9Zok/hEou7/zc= X-Google-Smtp-Source: ABdhPJw4To38qqbtMbWsu2GVi6Gw9ocAspw9oF440RulDevoGciHimaO1rOe2hGhXc80iN8V0eX0ywtWOIKX0AP94G0= X-Received: by 2002:a25:5106:: with SMTP id f6mr23191237ybb.176.1609547845684; Fri, 01 Jan 2021 16:37:25 -0800 (PST) MIME-Version: 1.0 References: <20201218175241.GA72552@spindle.one-eyed-alien.net> <20201218182820.1P0tK%steffen@sdaoden.eu> <20201223023242.GG31099@funkthat.com> <20201223162417.v7Ce6%steffen@sdaoden.eu> <20201229011939.GU31099@funkthat.com> <20201229210454.Lh4y_%steffen@sdaoden.eu> <20201230004620.GB31099@funkthat.com> <20201231193908.GC31099@funkthat.com> <20210101140857.x3hbci6c4nwi7gl7@mutt-hbsd> In-Reply-To: From: Li-Wen Hsu Date: Sat, 2 Jan 2021 08:37:14 +0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: HEADS UP: FreeBSD src repo transitioning to git this weekend To: Christian Weisgerber Cc: freebsd-current Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 02 Jan 2021 00:37:26 -0000 On Sat, Jan 2, 2021 at 4:25 AM Christian Weisgerber wrote: > > On 2021-01-01, Shawn Webb wrote: > > > This is why I asked FreeBSD to provide anonymous read-only ssh:// > > support for git. I'm very grateful they support it. > > > > One thing that I need to do with the HardenedBSD infrastructure is > > publish on our site the ssh pubkeys of the server (both RSA and > > ed25519). I plan to do that sometime this coming week. I wonder if it > > would be a good idea for FreeBSD to do the same > > The draft FreeBSD Git docs have the SSH fingerprints of the Git > servers. > https://github.com/bsdimp/freebsd-git-docs/blob/main/URLs.md > > Here's one from my own ~/.ssh/known_hosts: > SHA256:y1ljKrKMD3lDObRUG3xJ9gXwEIuqnh306tSyFd1tuZE git.freebsd.org (ED25519) And the ssh-keys file is available on the project site, signed with security-officer's key: https://www.freebsd.org/internal/ssh-keys.asc And in that file's header: """ Note that all machines listed below also have signed SSHFP records in DNS. If you have a DNSSEC-aware resolver and set VerifyHostKeyDNS to "ask" or "yes" in ~/.ssh/config, OpenSSH will verify host keys against these SSHFP records. """ Best, Li-Wen From owner-freebsd-current@freebsd.org Sat Jan 2 01:53:43 2021 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 D80CE4BD9BE for ; Sat, 2 Jan 2021 01:53:43 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wm1-x334.google.com (mail-wm1-x334.google.com [IPv6:2a00:1450:4864:20::334]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature 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 4D74gB63vjz4hNW for ; Sat, 2 Jan 2021 01:53:42 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: by mail-wm1-x334.google.com with SMTP id e25so11375267wme.0 for ; Fri, 01 Jan 2021 17:53:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=Cwteu1xKTzh/uxRjOcLz7HH1vuet98AzILIWbtfPEL8=; b=JryjyR19FJvHd4tFEWM9l/KbLsCnFgDyWf/MtokVM7ZTRFYC4fN5SOBkRWslgmm/E4 MqAkvl6M1CXjoj0MUmmijzHeeJL2H5vJoeECNFvEWUVlBS26hz3QlUyna6aeoTMPUqfP R3snsaERGZO+BiN83cfOAt2A9dj6GVz7wuTcq94cRrX6ym9WxXXRLfGE9l75qgjPZ1Qp zh3XyGePFSspuqUaw6RKQ6rtmDwCKs/Hli1iBaJtVQyHo2Ie/zplVnKzQuHXylzpZE5H Dk0fcMuI9/3W424EJF3sVOKx/L1dFWtPKZAnTwWKSEaSTI7ulXtBVnoHtN/sYwMyAUZv +HCQ== X-Gm-Message-State: AOAM530bx76LAa06iyx5lZZv5lN8I9QIFBD2MZ/V9Q7UzjDrQFiKPjua diltSJVGhj5A6HDCwZezAm17owFAFi7Ylw== X-Google-Smtp-Source: ABdhPJzzsdS3rmoES5XTPLceN3esMur0ORn95UHSWO6m8H4CSeIM23VM5K6tdCwoIpIALPWqK12raw== X-Received: by 2002:a1c:e306:: with SMTP id a6mr17714982wmh.66.1609552419399; Fri, 01 Jan 2021 17:53:39 -0800 (PST) Received: from [192.168.1.11] (79-66-147-78.dynamic.dsl.as9105.com. [79.66.147.78]) by smtp.gmail.com with ESMTPSA id i7sm78499994wrv.12.2021.01.01.17.53.38 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 01 Jan 2021 17:53:38 -0800 (PST) Subject: Re: mergemaster option -p To: freebsd-current@freebsd.org References: <87lfdctq83.wl-herbert@gojira.at> <87k0swtipr.wl-herbert@gojira.at> From: Graham Perrin Message-ID: <2ceaa92e-0b42-43a3-a692-18aa387d551d@gmail.com> Date: Sat, 2 Jan 2021 01:53:38 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <87k0swtipr.wl-herbert@gojira.at> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-Rspamd-Queue-Id: 4D74gB63vjz4hNW X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.70 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.70)[-0.696]; RECEIVED_SPAMHAUS_PBL(0.00)[79.66.147.78:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a00:1450:4864:20::334:from]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[2a00:1450:4864:20::334:from:127.0.2.255]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::334:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 02 Jan 2021 01:53:43 -0000 On 01/01/2021 22:06, Herbert J. Skuhra wrote: > On Fri, 01 Jan 2021 21:29:45 +0100, Graham Perrin wrote: >> On 01/01/2021 19:24, Herbert J. Skuhra wrote: >> >>> On Fri, 01 Jan 2021 20:01:16 +0100, Graham Perrin wrote: >>> >>>> … >>>> >>>> I did try `mergemaster -p` and somehow (!) ended up with an empty >>>> `/etc/group` file. Dug myself out of that hole, I'll prefer to >>>> continue using etcupdate. >>> -m /path/to/sources >>> Specify the path to the directory where you want to do the >>> make(1). >> >> Thank you, what path would you suggest? >> >> (Given the previous weirdness, I want to make no guesses here.) > 1. Your SOURCEDIR is /usr/src/freebsd-current and not /usr/src. > > Unlike etcupdate mergemaster checks for Makefile1.inc in the working > directory and asks to set SOURCEDIR accordingly: > > *** /usr/src was not found. > Found Makefile.inc1 in the current directory. > Would you like to set SOURCEDIR to /mnt2/src? [no and exit] > > Did you see this prompt? I do not recall seeing that prompt for the first run. I do recall responding 'yes' during a subsequent run. I did not note the exact name of the file but Makefile.inc1 is familiar. > 2. Do you have (old) files (e.g. Makefile.inc1) or directories > (e.g. etc) in /usr/src? No. Re: and I was careful to remove everything before builds and installations began. > Is this problem reproducible? Does it work if use -m switch, e.g: > 'mergemaster -m .' or 'mergemaster -m /usr/src/freebsd-current'? I might experiment when I next update the system. In the meantime, is it relevant to note that I prefer nano (not vi) for EDITOR and VISUAL? IIRC – probably reproducible – after previewing the changes to /etc/group I keyed 'm' and that's when the on-screen weirdness began. > Herbert Many thanks for taking an interest. Graham From owner-freebsd-current@freebsd.org Sat Jan 2 02:12:58 2021 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 8422E4BE253 for ; Sat, 2 Jan 2021 02:12:58 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D755Q2jttz4j1D for ; Sat, 2 Jan 2021 02:12:57 +0000 (UTC) (envelope-from shawn.webb@hardenedbsd.org) Received: by mail-qt1-x834.google.com with SMTP id b9so15074405qtr.2 for ; Fri, 01 Jan 2021 18:12:57 -0800 (PST) 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:references :mime-version:content-disposition:in-reply-to; bh=KeQAXs5K5C00cEoHuOyDYIlTiUdLNaemRyMRrKQ5Viw=; b=WvTrudg/a3bOhBM6MjiQM0TJfd8016oYo4/5QPwzkfkXKPhDT9eubxVcCG1ZuBAA8r aqVOmKbqDM5/2c15L+tUkEkAoB0HYf48WCgEq0l5goCwbQ+BLMYbAW3UUT7VCeGIsgIM X7X48jfyOVnrqQ3IC21kwP8HLpfwn3sFZ+iEHGQFEBgKYTugUKCBSM+V3HetYIwm7PfD x4kC+j8hjPP6NLI5wG9zffwFba4CZBkMhKBWxcYuchBaF+X4u18CuilhwXY7E2tKoRK4 I5iFy61WvcDEtMMnX9UQIFZaFyd63nUQUkCVKsh6BNsGZ0cibV1xyAq9kNWZbFArP1mF 2ZPQ== X-Gm-Message-State: AOAM530tPRHYS3UR86sEbD9m6rb3oLwx1q9OUrmisiEwtHTpofdPnBmw AFFeUXXCc2x3JbokwMxg+0WfDw== X-Google-Smtp-Source: ABdhPJyQ1ZKA3mFqqFl0C9S8o7pGW8Q935XtIQcmeuxchLHBwIvBiNvNKFqoVbL0IYuf2yUgl8cr8A== X-Received: by 2002:ac8:58c7:: with SMTP id u7mr63033863qta.54.1609553576373; Fri, 01 Jan 2021 18:12:56 -0800 (PST) Received: from mutt-hbsd (pool-100-16-222-53.bltmmd.fios.verizon.net. [100.16.222.53]) by smtp.gmail.com with ESMTPSA id o4sm31479686qta.26.2021.01.01.18.12.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 01 Jan 2021 18:12:55 -0800 (PST) Date: Fri, 1 Jan 2021 21:12:54 -0500 From: Shawn Webb To: Li-Wen Hsu Cc: Christian Weisgerber , freebsd-current Subject: Re: HEADS UP: FreeBSD src repo transitioning to git this weekend Message-ID: <20210102021254.35o3snqb5fcvmbt3@mutt-hbsd> X-Operating-System: FreeBSD mutt-hbsd 13.0-CURRENT-HBSD FreeBSD 13.0-CURRENT-HBSD X-PGP-Key: http://pgp.mit.edu/pks/lookup?op=vindex&search=0xFF2E67A277F8E1FA References: <20201223162417.v7Ce6%steffen@sdaoden.eu> <20201229011939.GU31099@funkthat.com> <20201229210454.Lh4y_%steffen@sdaoden.eu> <20201230004620.GB31099@funkthat.com> <20201231193908.GC31099@funkthat.com> <20210101140857.x3hbci6c4nwi7gl7@mutt-hbsd> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="f7x6mvr3uryud7cy" Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 4D755Q2jttz4j1D X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 02 Jan 2021 02:12:58 -0000 --f7x6mvr3uryud7cy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jan 02, 2021 at 08:37:14AM +0800, Li-Wen Hsu wrote: > On Sat, Jan 2, 2021 at 4:25 AM Christian Weisgerber = wrote: > > > > On 2021-01-01, Shawn Webb wrote: > > > > > This is why I asked FreeBSD to provide anonymous read-only ssh:// > > > support for git. I'm very grateful they support it. > > > > > > One thing that I need to do with the HardenedBSD infrastructure is > > > publish on our site the ssh pubkeys of the server (both RSA and > > > ed25519). I plan to do that sometime this coming week. I wonder if it > > > would be a good idea for FreeBSD to do the same > > > > The draft FreeBSD Git docs have the SSH fingerprints of the Git > > servers. > > https://github.com/bsdimp/freebsd-git-docs/blob/main/URLs.md > > > > Here's one from my own ~/.ssh/known_hosts: > > SHA256:y1ljKrKMD3lDObRUG3xJ9gXwEIuqnh306tSyFd1tuZE git.freebsd.org (ED2= 5519) >=20 > And the ssh-keys file is available on the project site, signed with > security-officer's key: >=20 > https://www.freebsd.org/internal/ssh-keys.asc >=20 > And in that file's header: > """ > Note that all machines listed below also have signed SSHFP records in > DNS. If you have a DNSSEC-aware resolver and set VerifyHostKeyDNS to > "ask" or "yes" in ~/.ssh/config, OpenSSH will verify host keys against > these SSHFP records. > """ Awesome! Thanks for the clarification! Thanks, --=20 Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Sha= wn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc --f7x6mvr3uryud7cy Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEA6TL67gupaZ9nzhT/y5nonf44foFAl/v1qMACgkQ/y5nonf4 4fofSQ//eqjfiHDWmJlHUWaHjaYCJNwHrm2CCqacaPWEMjk2rJFm654n6EGYsS5S aAi77DuMYtkC9hUHKdlFqmvRmNxiFXe+R686XBOHYD1fv6Lwayq83phuoNr5Vi3l ORgqKUa15D4SgqOInq1yP8t/LHs9b6+/PSRN65R9cajzn3F7I8e4rDyzmEZR6T+P r40vkNoViciYl3YGom6a1RPV/ZkoR5yXlLQ1vi1BzM17QNyno6cUfH5odkbvZj+1 b/unuS4Poa1qQuR6Phzp54Fde/+NLdz3XmVFmo0iGO/4qyr9IIP+0chduJ3hvyfU NiESuspOjLdhLgBgnphMdZQbIxJc/NMbEC8ffabNOt4kSUvtz1IBnOivusql0PnL XsZK0A0xdy7pysSWhwFtXiBGG8r4jtRaNArDcJVNN9F3gUmY9Z4Icr/cfXN6/COf 460mY+4ehJnJfvKgl4G0zoYkdg/d/T5eeTCWARLTabXmQycQq4oegI5QKxkLCrV7 Zbgu0yf0V6jlSbeBweMpkSrdVvDP/WVgtRZCOovRP42C2Zn4xKQh+3J1Z/J69vfG D3N5ApliCYQH3PiAMkZ4eivxSSyM4YodAA+3eUebnds5agpq+F1aP0uLSJW4EQuc 4WPt2h1A351OLg234/kUhANYw22syI9+/4Vlos++AqKrp3V4c4c= =wUoA -----END PGP SIGNATURE----- --f7x6mvr3uryud7cy-- From owner-freebsd-current@freebsd.org Sat Jan 2 05:25:55 2021 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 6352E4C2D63; Sat, 2 Jan 2021 05:25:55 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D79N20sX7z3C0C; Sat, 2 Jan 2021 05:25:53 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: by mail-lf1-x135.google.com with SMTP id m25so51852398lfc.11; Fri, 01 Jan 2021 21:25:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:subject:message-id:mime-version :content-transfer-encoding; bh=6iDYSKTkEb75yo2men6ijWcGFi7LEXYAOF1HoRh9aus=; b=OYZ0TSqr5EWGjcVKBf23JfQlyL4b/PTSZe1W6Y3AnbnGgJ3Nq+dPWq9TwAHBMaCGvL T4AAwHSEh+71yA8dO1h7LMNzpbfHHa7a2sr3tmOmKavlRXJHtUJLnQt4vHuzpWB9GNPN YzcWAfqqkxaPgi46u1MA5M6d5guhyS2Q+H+6ywTwhMpzVJCOynaRjxTXhFHM+5PR/pr4 ueGL2icVmoR+bc+e8RAqB4Nx8u2DgU8n42k7KPB4NaxR58rpPLqDgZJE3yLlPtpc2q4F +/SZ+fx19kr2pLJn564EAx1qn2ccQsu6rualq+jlmZ4z3khDsn699d2xaZZES+vtBcSJ tuzg== X-Gm-Message-State: AOAM5339zuEhY3/7J8Q9pCCV3f8YMz9r1BoqBzZSF1j9SNF0f5jm+pdB CK4ewpQbOndC8UfKWKGevP+ca2whI38= X-Google-Smtp-Source: ABdhPJxVSpS0tsygh0RynVH5IGauRgMWhUc0y4+DWJ1tWE38UV0o1iWNkoOjAJtaTrUd/NjeBib+4w== X-Received: by 2002:a05:6512:21d:: with SMTP id a29mr25692044lfo.444.1609565152205; Fri, 01 Jan 2021 21:25:52 -0800 (PST) Received: from rimwks.local ([2001:470:1f15:3d8:7285:c2ff:fe37:5722]) by smtp.gmail.com with ESMTPSA id v14sm4224400lfd.69.2021.01.01.21.25.50 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 01 Jan 2021 21:25:51 -0800 (PST) From: Rozhuk Ivan X-Google-Original-From: Rozhuk Ivan Date: Sat, 2 Jan 2021 08:25:49 +0300 To: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Subject: Terminal colours in current Message-ID: <20210102082549.758bd189@rimwks.local> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; amd64-portbld-freebsd12.2) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4D79N20sX7z3C0C X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a00:1450:4864:20::135:from]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_SHORT(1.00)[1.000]; SPAMHAUS_ZRD(0.00)[2a00:1450:4864:20::135:from:127.0.2.255]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::135:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current,freebsd-hackers] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 02 Jan 2021 05:25:55 -0000 Hi! I am tring current and found that kernel options: options TERMINAL_NORM_ATTR = (FG_GREEN|BG_BLACK) # def to SC_NORM_ATTR / 2 | 0x00 options TERMINAL_KERN_ATTR = (FG_YELLOW|BG_BLACK) # def to SC_KERNEL_CONS_ATTR / 14 / 0x00 does not work anymore. Fast greping sources give me loader tunables: teken.fg_color="2" # teken.bg_color="0" # but these optios does not allow set kernel messages colour. https://www.freebsd.org/cgi/man.cgi?query=vt&apropos=0&sektion=4&manpath=FreeBSD+13.0-current&arch=default&format=html say that TERMINAL_NORM_ATTR and TERMINAL_KERN_ATTR should work. Also it say that I should have: kern.vt.color..rgb="" kern.vt.fb.default_mode="x" kern.vt.fb.modes.="x" but I only get: kern.vty: vt kern.vt.splash_cpu_duration: 10 kern.vt.splash_cpu_style: 2 kern.vt.splash_ncpu: 0 kern.vt.splash_cpu: 0 kern.vt.kbd_panic: 0 kern.vt.kbd_debug: 0 kern.vt.kbd_reboot: 0 kern.vt.kbd_poweroff: 0 kern.vt.kbd_halt: 0 kern.vt.suspendswitch: 0 kern.vt.deadtimer: 15 kern.vt.debug: 0 kern.vt.enable_bell: 0 kern.vt.enable_altgr: 1 Do I miss something? From owner-freebsd-current@freebsd.org Sat Jan 2 05:34:06 2021 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 1B3874C3170; Sat, 2 Jan 2021 05:34:06 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D79YS5BTFz3CxD; Sat, 2 Jan 2021 05:34:04 +0000 (UTC) (envelope-from ohartmann@walstatt.org) X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from hermann.fritz.box ([77.11.157.193]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1M26vL-1ky3SF1h5l-002V9y; Sat, 02 Jan 2021 06:34:02 +0100 Date: Sat, 2 Jan 2021 06:33:55 +0100 From: "Hartmann, O." To: Rozhuk Ivan Cc: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Terminal colours in current Message-ID: <20210102063355.1be83a57@hermann.fritz.box> In-Reply-To: <20210102082549.758bd189@rimwks.local> References: <20210102082549.758bd189@rimwks.local> Organization: walstatt.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/hZKd4gHkKmK4/heR+9dQEAa"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Provags-ID: V03:K1:pTVEg6lGtFRBh7IXHVoEAj7p/+0e3Nj9Wv1G2M9T5FGV4SYlz73 w4vRgteoLbC3Vpe2T0IcJ9G41xJM9IoKN3XANzU4JGHgefwvBXfImKvLshh1YqX0V69u8jG axPgYJow+KZ87AnXaIh3C+NYJyXMUCVlvCMs7pUQvPgaH0qUDRTvhxnRcs6TmDIv+M8a+W1 lvMK33rsyKVSK2NjONobw== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:3+/lL0j45j8=:kU0ewawbVbmfOEWYYAoX+4 cV8KWPUvaCH0P8hO4nn43C9DljieJpYKOK6rnuJX5bJ3NDZcW1s4pRjJ7N2qPWYmEfcgnfsf5 sSlyZX9MvilZMp+2GdazUEwkpi/f32uDFyNstlwHzVpGGdFfRO9iSvDu01C0vEkTscDiYMK66 8h/GNMqK+WzireVUfdSzQjaFBruS1dVWDt15X6ybmqZQyn7W38RFwTVn9WGEgAbGNw3XoFd/9 ZkWJ3vWR+n81FQKdUj6GrjxH6g+wsp1pii/uRBGevLSPmE3Q31H+ec42li44Eub+S21ysTiIX 8N6zI+OtXgJt0BFhBfperSLp9TTk4kcD9/kvQhgIBfHdDm1SHl77/lDP1pNO4OjG70IAJuino tEA9YyTXDbzd3L5TvakWrejlcwEJrsbWdLOTYxZ+fJ6I9fpZhXMpAUA+YQ/f1b39c4y7cBXEz rwaOw85le1NQ29aUL5QOyyxAjIR9j2L4FsvG/NvAhbn+IeqoCLTLs/UBIXfE8LDMvxRksP0NA nI6nEiffdzBSQiEMcoCaW92psOrQl5JkrfEuEVlhTQDTWgc9dKO5JMxt11xwhyD9Srxg968bu PBVSnd8uoJOtO89b6brO4pdqTUm23q2HCHk02U6x8+ri0cKl6Hk5z0DIu1fNUqcZFVRNTKCFX VGRiQxnY+PVE2bdk7e6Rxri4TKPBseiTps0+CkJe+lWDqxe+oER2RHiP0dIE/b/j9f2cXSlqI W67ACNaMqVEQSlAr5HmbuUTge9zca+4FdMtefoQSkyN6tbRlOsT/Peaeo/jJIPYPfoxmlRc7n EpT9cSt/sQ7OJIT/ymnwEWxYpS7isW8sAH7VRH8l5QWEsxcvKkTzLB31imrqpS1qQgoTq/svI PFkRubMdTrzdFw54mZZA== X-Rspamd-Queue-Id: 4D79YS5BTFz3CxD X-Spamd-Bar: - X-Spamd-Result: default: False [-1.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; HAS_ORG_HEADER(0.00)[]; DKIM_TRACE(0.00)[gmx.net:+]; FREEMAIL_TO(0.00)[gmail.com]; RECEIVED_SPAMHAUS_PBL(0.00)[77.11.157.193:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RBL_DBL_DONT_QUERY_IPS(0.00)[212.227.15.19:from]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE]; RCVD_IN_DNSWL_LOW(-0.10)[212.227.15.19:from]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmx.net:s=badeba3b8450]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(1.00)[1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[walstatt.org]; SPAMHAUS_ZRD(0.00)[212.227.15.19:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_NA(0.00)[no SPF record]; RWL_MAILSPIKE_POSSIBLE(0.00)[212.227.15.19:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current,freebsd-hackers] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 02 Jan 2021 05:34:06 -0000 --Sig_/hZKd4gHkKmK4/heR+9dQEAa Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sat, 2 Jan 2021 08:25:49 +0300 Rozhuk Ivan wrote: > Hi! >=20 > I am tring current and found that kernel options: > options TERMINAL_NORM_ATTR =3D (FG_GREEN|BG_BLACK) # def to > SC_NORM_ATTR / 2 | 0x00 options TERMINAL_KERN_ATTR =3D > (FG_YELLOW|BG_BLACK) # def to SC_KERNEL_CONS_ATTR / 14 / 0x00 does not wo= rk anymore. >=20 > Fast greping sources give me loader tunables: > teken.fg_color=3D"2" # > teken.bg_color=3D"0" # >=20 > but these optios does not allow set kernel messages colour. >=20 > https://www.freebsd.org/cgi/man.cgi?query=3Dvt&apropos=3D0&sektion=3D4&ma= npath=3DFreeBSD+13.0-current&arch=3Ddefault&format=3Dhtml > say that TERMINAL_NORM_ATTR and TERMINAL_KERN_ATTR should work. > Also it say that I should have: > kern.vt.color..rgb=3D"" > kern.vt.fb.default_mode=3D"x" > kern.vt.fb.modes.=3D"x" > but I only get: > kern.vty: vt > kern.vt.splash_cpu_duration: 10 > kern.vt.splash_cpu_style: 2 > kern.vt.splash_ncpu: 0 > kern.vt.splash_cpu: 0 > kern.vt.kbd_panic: 0 > kern.vt.kbd_debug: 0 > kern.vt.kbd_reboot: 0 > kern.vt.kbd_poweroff: 0 > kern.vt.kbd_halt: 0 > kern.vt.suspendswitch: 0 > kern.vt.deadtimer: 15 > kern.vt.debug: 0 > kern.vt.enable_bell: 0 > kern.vt.enable_altgr: 1 >=20 >=20 > Do I miss something? >=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" Colour settings seem to be broken since a couple of months. Out of the blue= , coloured kernel messages vanished - this problem is on 12 as well as CURRENT (we're = running 12.2-RELENG, 12-STABLE and CURRENT). Kind regards, O. Hartmann --Sig_/hZKd4gHkKmK4/heR+9dQEAa Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQSy8IBxAPDkqVBaTJ44N1ZZPba5RwUCX/AFwwAKCRA4N1ZZPba5 R9vIAP455rbbEiifgL3MfQeivQabAb9Tw0N4NBCdMp1j47vXcAD/bZ7hToDF0DM3 FW9X0saOwk7IiRSlasfQSX1bByYepQ0= =SXF0 -----END PGP SIGNATURE----- --Sig_/hZKd4gHkKmK4/heR+9dQEAa-- From owner-freebsd-current@freebsd.org Sat Jan 2 05:41:00 2021 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 051584C3CB7; Sat, 2 Jan 2021 05:41:00 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D79jR21FPz3DGj; Sat, 2 Jan 2021 05:40:59 +0000 (UTC) (envelope-from rozhuk.im@gmail.com) Received: by mail-lf1-x12d.google.com with SMTP id 23so51874540lfg.10; Fri, 01 Jan 2021 21:40:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:date:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=Dla2S2fUhnZL4KgTZiOnVAUt42CB8brcch8ZjAFTa1A=; b=BBM8yyuLvuDTdtbj2ZhLaoMoojYj6HLKxnJbLf/udtCMhpL2V8RpF7qTWuyo25IqUb KsVtfFz945c8+N44/xeR39jvd6DDhuvVIOgql8Kj6BdEt8bjcnxJn8Tlo+ZuFM87VXo0 Xwzb9dPY+Q6c8UrdR2Pmc4Gv32UmsOHGHN61nhlbtC+5xEj+IXWeksLGGCUDW9FAWHyZ kGszhKdnGxVko2NoKfpD6pMsWuqOiiamWO3ejv+SJ8ms8C4fiez+AcPeFzoPcSFJH5t3 IeAJVeF0xnp0r/HLSolSD6mWqcy5Se14egeKtB+ePzx4VfNPrT1rTHsK3rMAkJ8ODJbg 7eWg== X-Gm-Message-State: AOAM531WIY+EzrOhpgMkoefVV+8cIzQB1IQHgrMJD7435hgweK71rgJ7 hdOsVCwr5rIpxmOZsVQmH/WbvsGeTvw= X-Google-Smtp-Source: ABdhPJz/xZzjryEwOXNwqRpng82qI0qmNLpgwl7XHze8oiHj81a9NHkzz0Dno7DkFaIqEBHU+tHr/w== X-Received: by 2002:a2e:87d3:: with SMTP id v19mr32823127ljj.207.1609566057489; Fri, 01 Jan 2021 21:40:57 -0800 (PST) Received: from rimwks.local ([2001:470:1f15:3d8:7285:c2ff:fe37:5722]) by smtp.gmail.com with ESMTPSA id d2sm8078117ljg.39.2021.01.01.21.40.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 01 Jan 2021 21:40:57 -0800 (PST) From: Rozhuk Ivan X-Google-Original-From: Rozhuk Ivan Date: Sat, 2 Jan 2021 08:40:55 +0300 To: "Hartmann, O." Cc: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: Terminal colours in current Message-ID: <20210102084055.2eebbcfd@rimwks.local> In-Reply-To: <20210102063355.1be83a57@hermann.fritz.box> References: <20210102082549.758bd189@rimwks.local> <20210102063355.1be83a57@hermann.fritz.box> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; amd64-portbld-freebsd12.2) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4D79jR21FPz3DGj X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a00:1450:4864:20::12d:from]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(1.00)[1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[2a00:1450:4864:20::12d:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::12d:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current,freebsd-hackers] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 02 Jan 2021 05:41:00 -0000 On Sat, 2 Jan 2021 06:33:55 +0100 "Hartmann, O." wrote: > Colour settings seem to be broken since a couple of months. Out of > the blue, coloured kernel messages vanished - this problem is on 12 > as well as CURRENT (we're running 12.2-RELENG, 12-STABLE and CURRENT). > I do no see problem on stable 12. Also current with loaders from 12 is OK. From owner-freebsd-current@freebsd.org Sat Jan 2 06:04:35 2021 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 717614C44CA for ; Sat, 2 Jan 2021 06:04:35 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D7BDf2Dcvz3FYH for ; Sat, 2 Jan 2021 06:04:33 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from hermann.fritz.box ([77.11.157.193]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1Mz9Yv-1k1R0O3uT5-00wEB0; Sat, 02 Jan 2021 07:04:32 +0100 Date: Sat, 2 Jan 2021 07:04:31 +0100 From: "Hartmann, O." To: Rozhuk Ivan Cc: "Hartmann, O." , freebsd-current@freebsd.org Subject: Re: Terminal colours in current Message-ID: <20210102070431.2c12993d@hermann.fritz.box> In-Reply-To: <20210102084055.2eebbcfd@rimwks.local> References: <20210102082549.758bd189@rimwks.local> <20210102063355.1be83a57@hermann.fritz.box> <20210102084055.2eebbcfd@rimwks.local> Organization: walstatt.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/no7LiaAfyobTNIoiMAc4Hnc"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Provags-ID: V03:K1:JA6yVsrIPeF6PQncwDAO7Xplf4Fko6Fq8xUvXAVOdrEuuLeMaYm wYsXVltD81etGe5O4hcczI8x7MLGpWm+hjfW7Eh19r+y62qiEQGoKu2bUIuL3y/kMiH5SkM J8WZrx389sUWNzVn10xjmOOpYmhbqQmQo9fkj3NaP/KyGBrXFeyqEDaFLfQMTo2vLr8kzFf LPqKkLQoF9WV22fFhViNA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:kCCoYYERUqs=:Hjlw3TYtCrRaJSsSEGpVZR fJAhy2C4PK/OVjx7h3qmTb3CPa9nQJuTHZVs88tCFrud5v8E0xO+O96YKIzyXhwtjyjKlLA+e PcUqMAYlOv1pjJvAyAbMbn9TRLLJfliuotorqxXizKZ1R5R7Z/U8+S1KLWt/gr2bPvQPO2wWf pZWsV/ptMcdIWcObMwqyxzqLYiBHDWTsdO0CeJ4iGf9ckQkj20Fba6ZdjlD5FowLcfUwJeT+Z Ipj9DK6T5sz3iKC1nQXi5S+BD+UMeXBWolxO2hipdr5iUHUAUnEhzZ3MJvZMa+pkt8/C6JzxJ t2kTG2+cfbYBVRdsDwj0/pq8m1IUkyHBUeL2mLlj5dkJ272txiS0NxohggSaYNHe9ziYZFjiT bmWjImrNJwsIRLG79A+ZzJwSNcUq/K4V2+dxlB5rK4+SPugAJKrYQ/3U0oHa6kX3xO+U056zX IU+4GWdMNr3jVMPU/MsIE5P8c4imqlk9LrTqebhEOsaN0HAGYKFCtuZOizjh6plHvPfM1vMFk PIs3GlCIDjRfPEof3zircqSpVWMfit4xrFseVaHd32aFSUh8wRDtK0AYyTwQmZUsZgp57HsuF Rj7F6X+QkZ3TD9SMnKc5NwjH9vW6Y5m30ePn2U/fLeXduS9/QTdXVOYEYIokBI/FfDWWY93Zq e4Wv7O5chz6AEpB0947CG4uiZdTcWjMa8mFTbpK1HgTyub+Ke4c0wybRgjjYwi73BXb5DeT+E q7BR8Zqtz2OUCTVNdviK6sI/V/o+yxnxTIsTJLl704CkstvP8PniqPQjEE3MfTzCqJ8m++sbj E6FW7aWNWMhkJpE8j2cVP95vPXgCP6ID9cCcOLxrqbATEW5ujJBZVp1u4tkK2kExAgOcUVBNJ CmEbs9jixZObAIcqxbAQ== X-Rspamd-Queue-Id: 4D7BDf2Dcvz3FYH X-Spamd-Bar: - X-Spamd-Result: default: False [-1.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; HAS_ORG_HEADER(0.00)[]; DKIM_TRACE(0.00)[gmx.net:+]; FREEMAIL_TO(0.00)[gmail.com]; RECEIVED_SPAMHAUS_PBL(0.00)[77.11.157.193:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RBL_DBL_DONT_QUERY_IPS(0.00)[212.227.15.18:from]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE]; RCVD_IN_DNSWL_LOW(-0.10)[212.227.15.18:from]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmx.net:s=badeba3b8450]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_SPAM_SHORT(1.00)[1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[walstatt.org]; SPAMHAUS_ZRD(0.00)[212.227.15.18:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_NA(0.00)[no SPF record]; RWL_MAILSPIKE_POSSIBLE(0.00)[212.227.15.18: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.34 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, 02 Jan 2021 06:04:35 -0000 --Sig_/no7LiaAfyobTNIoiMAc4Hnc Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sat, 2 Jan 2021 08:40:55 +0300 Rozhuk Ivan wrote: > On Sat, 2 Jan 2021 06:33:55 +0100 > "Hartmann, O." wrote: >=20 > > Colour settings seem to be broken since a couple of months. Out of > > the blue, coloured kernel messages vanished - this problem is on 12 > > as well as CURRENT (we're running 12.2-RELENG, 12-STABLE and CURRENT). > > =20 >=20 > I do no see problem on stable 12. > Also current with loaders from 12 is OK. That is interesting! --Sig_/no7LiaAfyobTNIoiMAc4Hnc Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQSy8IBxAPDkqVBaTJ44N1ZZPba5RwUCX/AM7wAKCRA4N1ZZPba5 R44zAP9k6pwwis3InCDYacV9pTyR6DzsrT5Vzu+mJViE+Voh+wEA0C0VM5muNQy1 GowyK9M3EoU1rXw43xy+5sK0Lt3QCQA= =7Vo3 -----END PGP SIGNATURE----- --Sig_/no7LiaAfyobTNIoiMAc4Hnc-- From owner-freebsd-current@freebsd.org Sat Jan 2 07:36:06 2021 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 3AFE64C60E0 for ; Sat, 2 Jan 2021 07:36:06 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4D7DGG0Qvtz3JyL; Sat, 2 Jan 2021 07:36:05 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (v-critter.freebsd.dk [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id 8D58B8A3C5; Sat, 2 Jan 2021 07:35:58 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.16.1/8.16.1) with ESMTPS id 1027Zwmf060084 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 2 Jan 2021 07:35:58 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.16.1/8.16.1/Submit) id 1027ZvoB060083; Sat, 2 Jan 2021 07:35:57 GMT (envelope-from phk) To: Shawn Webb cc: Li-Wen Hsu , Christian Weisgerber , freebsd-current Subject: Re: HEADS UP: FreeBSD src repo transitioning to git this weekend In-reply-to: <20210102021254.35o3snqb5fcvmbt3@mutt-hbsd> From: "Poul-Henning Kamp" References: <20201223162417.v7Ce6%steffen@sdaoden.eu> <20201229011939.GU31099@funkthat.com> <20201229210454.Lh4y_%steffen@sdaoden.eu> <20201230004620.GB31099@funkthat.com> <20201231193908.GC31099@funkthat.com> <20210101140857.x3hbci6c4nwi7gl7@mutt-hbsd> <20210102021254.35o3snqb5fcvmbt3@mutt-hbsd> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <60081.1609572957.1@critter.freebsd.dk> Date: Sat, 02 Jan 2021 07:35:57 +0000 Message-ID: <60082.1609572957@critter.freebsd.dk> X-Rspamd-Queue-Id: 4D7DGG0Qvtz3JyL X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 02 Jan 2021 07:36:06 -0000 As interesting as this thread has been (not!), let me remind everybody that the cheapest, easiest and most efficient and profitable way for a Nation State Actor to trojan the FreeBSD code-base, is to assign an employee to a deniable job, and have them become a FreeBSD committer. No amount of cryptography can or will protect against that. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@freebsd.org Sat Jan 2 08:07:45 2021 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 27BB04C735D for ; Sat, 2 Jan 2021 08:07:45 +0000 (UTC) (envelope-from tsoome@me.com) Received: from st43p00im-zteg10073501.me.com (st43p00im-zteg10073501.me.com [17.58.63.180]) (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 4D7Dym2RBwz3LXN for ; Sat, 2 Jan 2021 08:07:44 +0000 (UTC) (envelope-from tsoome@me.com) Received: from nazgul.lan (148-52-235-80.sta.estpak.ee [80.235.52.148]) by st43p00im-zteg10073501.me.com (Postfix) with ESMTPSA id 1C1B5AE01E7; Sat, 2 Jan 2021 08:07:36 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\)) Subject: Re: Terminal colours in current From: Toomas Soome In-Reply-To: <20210102082549.758bd189@rimwks.local> Date: Sat, 2 Jan 2021 10:07:34 +0200 Cc: freebsd-current@freebsd.org, freebsd-hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <948C1DBA-4CC3-492D-BC9E-5E6502772667@me.com> References: <20210102082549.758bd189@rimwks.local> To: Rozhuk Ivan X-Mailer: Apple Mail (2.3654.40.0.2.32) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2021-01-02_05:2020-12-31, 2021-01-02 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-2101020049 X-Rspamd-Queue-Id: 4D7Dym2RBwz3LXN X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.50 / 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(-1.00)[-1.000]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[me.com]; ASN(0.00)[asn:714, ipnet:17.58.63.0/24, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[17.58.63.180:from]; DWL_DNSWL_NONE(0.00)[me.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[me.com:s=1a1hai]; FREEFALL_USER(0.00)[tsoome]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; SPAMHAUS_ZRD(0.00)[17.58.63.180:from:127.0.2.255]; RECEIVED_SPAMHAUS_PBL(0.00)[80.235.52.148:received]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[17.58.63.180: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.34 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, 02 Jan 2021 08:07:45 -0000 > On 2. Jan 2021, at 07:25, Rozhuk Ivan wrote: >=20 > Hi! >=20 > I am tring current and found that kernel options: > options TERMINAL_NORM_ATTR =3D (FG_GREEN|BG_BLACK) = # def to SC_NORM_ATTR / 2 | 0x00 > options TERMINAL_KERN_ATTR =3D (FG_YELLOW|BG_BLACK) = # def to SC_KERNEL_CONS_ATTR / 14 / 0x00 > does not work anymore. >=20 > Fast greping sources give me loader tunables: > teken.fg_color=3D"2" # > teken.bg_color=3D"0" # >=20 > but these optios does not allow set kernel messages colour. At this time, both TERMINAL_NORM_ATTR and TERMINAL_KERN_ATTR are set = based from teken.fg_color and teken.bg_color, to get consistent console = while transitioning from loader to kernel. >=20 > = https://www.freebsd.org/cgi/man.cgi?query=3Dvt&apropos=3D0&sektion=3D4&man= path=3DFreeBSD+13.0-current&arch=3Ddefault&format=3Dhtml > say that TERMINAL_NORM_ATTR and TERMINAL_KERN_ATTR should work. > Also it say that I should have: > kern.vt.color..rgb=3D"" This one is option to override RGB values for color identified by = colornum. FreeBSD console is only supporting colors 0-7 there (see = sys/terminal.h). However, this feature is only available for framebuffer = console (not vga graphics or text). > kern.vt.fb.default_mode=3D"x" > kern.vt.fb.modes.=3D"x" Those two affect KMS driver (if set). > but I only get: > kern.vty: vt > kern.vt.splash_cpu_duration: 10 > kern.vt.splash_cpu_style: 2 > kern.vt.splash_ncpu: 0 > kern.vt.splash_cpu: 0 > kern.vt.kbd_panic: 0 > kern.vt.kbd_debug: 0 > kern.vt.kbd_reboot: 0 > kern.vt.kbd_poweroff: 0 > kern.vt.kbd_halt: 0 > kern.vt.suspendswitch: 0 > kern.vt.deadtimer: 15 > kern.vt.debug: 0 > kern.vt.enable_bell: 0 > kern.vt.enable_altgr: 1 >=20 >=20 > Do I miss something? >=20 In current, You should get console colors as set in loader.=20 rgds, toomas From owner-freebsd-current@freebsd.org Sat Jan 2 08:31:46 2021 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 903B94C7E3D for ; Sat, 2 Jan 2021 08:31:46 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature 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 4D7FVT44FHz3Mct; Sat, 2 Jan 2021 08:31:45 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: by mail-wm1-x330.google.com with SMTP id g25so5403204wmh.1; Sat, 02 Jan 2021 00:31:45 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=kzSX+Pw4K+8Lfr4uXmYQCoYVYVoQJ/Gpk9InuZ5xSGc=; b=pk5q08LuC2mePq7UcgCcB3yPdnRUhOt3qZ1l+msLjNOhKOcSaqbwS4OKr7fwQUspBx Vw/zv2hgfRF/9hf0WwdcVOxOV2BxeJWNJfF8kqC25H1w7kukn+lMu3J/D+tr5ybMWPV+ uZbrDSakGJ1zPHFly6lgbqt+a8xLJSjYtLFPJVJVXxUswoK6XYaQpMohoeHsHSZN7t6H 6d2fGeToafC75gqMIv+8wvNMQ6oz7z5GXAgRULuYx+JphOzLxdA2sQUN1nhqvVF2GZKd DCV2FlNA3C/6Ytsh8AjOJxKRWGgMoQ55JN5DaRWmtE0IDL95rDmAZij9JlZStE0GsNsu hfAA== X-Gm-Message-State: AOAM530YRX24RqMATEFUOFwLj345hb3rzUvr4WLic3Zn6P0siXbFSen+ okIOCDAwHvuFK9yRN0K1Z1npb/C0NEWPZA== X-Google-Smtp-Source: ABdhPJy4jdz0mnwUUJwtaIm5OjynnOufdaIWee4uvUo1Oo51KIzwXQvd1wdkux5gW7KDb2cliL0rIg== X-Received: by 2002:a1c:bd09:: with SMTP id n9mr18032750wmf.32.1609576303003; Sat, 02 Jan 2021 00:31:43 -0800 (PST) Received: from [192.168.1.11] (79-66-147-78.dynamic.dsl.as9105.com. [79.66.147.78]) by smtp.gmail.com with ESMTPSA id a14sm76920682wrn.3.2021.01.02.00.31.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 02 Jan 2021 00:31:42 -0800 (PST) Subject: etcupdate, svnlite, documentation etc. following the transition of source to Git To: freebsd-current@freebsd.org References: <87lfdctq83.wl-herbert@gojira.at> Cc: Lars Engels From: Graham Perrin Message-ID: Date: Sat, 2 Jan 2021 08:31:36 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <87lfdctq83.wl-herbert@gojira.at> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-Rspamd-Queue-Id: 4D7FVT44FHz3Mct X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-0.996]; RECEIVED_SPAMHAUS_PBL(0.00)[79.66.147.78:received]; FROM_EQ_ENVFROM(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a00:1450:4864:20::330:from]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; SPAMHAUS_ZRD(0.00)[2a00:1450:4864:20::330:from:127.0.2.255]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::330:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 02 Jan 2021 08:31:46 -0000 On 01/01/2021 19:24, Herbert J. Skuhra wrote: > On Fri, 01 Jan 2021 20:01:16 +0100, Graham Perrin wrote: >> At what should have been the end of my first upgrade since the >> transition to git: >> >> cd /usr/src/freebsd-current && make installworld && etcupdate >> >> 𠄴– concluded with a successful installworld, then a few lines about >> scanning and skipping certificates, then: >> >>> Failed to build new tree. >> I see the manual page for etcupdate(8) but I'm not sure how to proceed. > -s source Specify an alternate source tree to use when building > or extracting a “current” tree. The default source > tree is /usr/src. With the transition to Git ========================== If it's true that /usr/src is _no longer_ a predictable path to the source files, then is it still appropriate for users' fortunes to include this FreeBSD tip? It is, still, essentially a smart tip (thank you, Lars) however some readers who have switched to the `git` approach might benefit from an additional hint to use option -s svnlite ======= still describes use of `svnlite` (not `git` or `got`) and, I guess, might continue to do so for some time. In this context, is `cd /usr/src` still true? ---- Thanks everyone From owner-freebsd-current@freebsd.org Sat Jan 2 08:47:11 2021 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 AA09E4C83A0 for ; Sat, 2 Jan 2021 08:47:11 +0000 (UTC) (envelope-from herbert@gojira.at) Received: from mail.bsd4all.net (mail.bsd4all.net [94.130.200.20]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail.bsd4all.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D7FrG2FvWz3ND9 for ; Sat, 2 Jan 2021 08:47:09 +0000 (UTC) (envelope-from herbert@gojira.at) Date: Sat, 02 Jan 2021 09:47:07 +0100 Message-ID: <87pn2nu3n8.wl-herbert@gojira.at> From: "Herbert J. Skuhra" To: freebsd-current@freebsd.org Subject: Re: etcupdate, svnlite, documentation etc. following the transition of source to Git In-Reply-To: References: <87lfdctq83.wl-herbert@gojira.at> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/28.0 Mule/6.0 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 4D7FrG2FvWz3ND9 X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.50 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gojira.at:s=mail202005]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:94.130.200.20]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[gojira.at]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[94.130.200.20:from:127.0.2.255]; DKIM_TRACE(0.00)[gojira.at:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MID_CONTAINS_FROM(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[94.130.200.20:from]; ASN(0.00)[asn:24940, ipnet:94.130.0.0/16, country:DE]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 02 Jan 2021 08:47:11 -0000 On Sat, 02 Jan 2021 09:31:36 +0100, Graham Perrin wrote: > > With the transition to Git > > ========================== > > If it's true that /usr/src is _no longer_ a predictable path to the > source files, then is it still appropriate for users' fortunes to > include this FreeBSD tip? > > > > It is, still, essentially a smart tip (thank you, Lars) however some > readers who have switched to the `git` approach might benefit from an > additional hint to use option -s > > svnlite > ======= > > > still describes use of `svnlite` (not `git` or `got`) and, I guess, > might continue to do so for some time. > > In this context, is `cd /usr/src` still true? If you clone the repository to /usr/src instead of e.g. /usr/src/freebsd-current. -- Herbert From owner-freebsd-current@freebsd.org Sat Jan 2 10:27:57 2021 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 CF9644CA717 for ; Sat, 2 Jan 2021 10:27:57 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D7J4Y1GFxz3hv0 for ; Sat, 2 Jan 2021 10:27:56 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: by mail-ed1-x536.google.com with SMTP id g24so21903711edw.9 for ; Sat, 02 Jan 2021 02:27:56 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=gNV5SIjrCHezQvqnxKdaA8dWeQayKOB2H2UGgBzRCYc=; b=nqB9WmyvO7FT9oGPPjjNaj4lcQkbCg3xeEvOJ1a+rTltQ5bCI5hfxt1dEzoM/iRy44 dipJ6QUmSX4LKxZktF0+e1cuNzKsMxNemEUBmMUAhy4aSRg4apy7xOVM8FTktgfyIR/E 1SV681KU7/SlbSCXoIoNHcj1pchc0Y2xlL8lSpX4hJ2qCY29EAoC1rZCHdnDBSrTV1Vm 2SnR1r4/eaSDsDLE30E2eQD3eHL8m5k0LaPV9x17Uzzup9H8aY9Tu07V6frXotdbewrP gWuV5JHlClqDMEyk0uuUkuuyokx8ho9rs7zVLr5q05Lk/6NOy4Gpy/ZtWLFhPgi4MyTe ev4Q== X-Gm-Message-State: AOAM531aXuy1Rb5CFq+WVxAGODeUPZ8sCMUDQw+FCUUh0angTyIp0csp ZYyRmDgH1sXvCJV/5hfs+oF2nkaDcu6nOWgktHQRB/ULyla3iw== X-Google-Smtp-Source: ABdhPJwPxfu4GZ4jguUKoSO9nugL+6/0Sp8hRpPTEpcsloiHY7Pkl8PjezVZjIeyxP855xdCOzWLocjZyIP7Os0XvLg= X-Received: by 2002:a05:6402:7d7:: with SMTP id u23mr61806140edy.325.1609583275256; Sat, 02 Jan 2021 02:27:55 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a54:3d8d:0:0:0:0:0 with HTTP; Sat, 2 Jan 2021 02:27:54 -0800 (PST) In-Reply-To: <60082.1609572957@critter.freebsd.dk> References: <20201223162417.v7Ce6%steffen@sdaoden.eu> <20201229011939.GU31099@funkthat.com> <20201229210454.Lh4y_%steffen@sdaoden.eu> <20201230004620.GB31099@funkthat.com> <20201231193908.GC31099@funkthat.com> <20210101140857.x3hbci6c4nwi7gl7@mutt-hbsd> <20210102021254.35o3snqb5fcvmbt3@mutt-hbsd> <60082.1609572957@critter.freebsd.dk> From: grarpamp Date: Sat, 2 Jan 2021 05:27:54 -0500 Message-ID: Subject: Re: HEADS UP: FreeBSD src repo transitioning to git this weekend To: freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4D7J4Y1GFxz3hv0 X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a00:1450:4864:20::536:from]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[2a00:1450:4864:20::536:from:127.0.2.255]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::536: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.34 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, 02 Jan 2021 10:27:57 -0000 > No amount of cryptography can or will protect against that. Though it can help attribute that to a source, else ignore rainbow books and go back to telnet, root password 'root', CVS, no backups, logs, etc. > As interesting as this thread has been (not!) Contrare. Equally as interesting as thread's and other details, is how to attend that too. Luck playing guess the mole and trying to SF-86 and p2p everyone only goes so far. Stronger layered yet is a [change] audit group, selected randomly and randomly rotated through, all who must approve. And to provide alt eyes and counter self project bias, a review trade market with other OS projects denominated in LOC [fair weighted by spaghetti and doc ratios]. Pay for more coverage by foundation holding back 1/4 of its crypto donations and mining as investment. Defense in depth. Have fun. From owner-freebsd-current@freebsd.org Sat Jan 2 13:10:27 2021 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 BF1AF4CF657 for ; Sat, 2 Jan 2021 13:10:27 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from dec.sakura.ne.jp (dec.sakura.ne.jp [210.188.226.8]) (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 4D7Mh23fNXz3rvH for ; Sat, 2 Jan 2021 13:10:26 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from kalamity.joker.local (115-38-187-204.shizuoka1.commufa.jp [115.38.187.204]) (authenticated bits=0) by dec.sakura.ne.jp (8.15.2/8.15.2/[SAKURA-WEB]/20080708) with ESMTPA id 102DAGj9055058 for ; Sat, 2 Jan 2021 22:10:16 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Sat, 2 Jan 2021 22:10:16 +0900 From: Tomoaki AOKI To: freebsd-current@freebsd.org Subject: Re: etcupdate, svnlite, documentation etc. following the transition of source to Git Message-Id: <20210102221016.fcd9c837b0e1e650d89c5fba@dec.sakura.ne.jp> In-Reply-To: <87pn2nu3n8.wl-herbert@gojira.at> References: <87lfdctq83.wl-herbert@gojira.at> <87pn2nu3n8.wl-herbert@gojira.at> Reply-To: junchoon@dec.sakura.ne.jp Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd12.1) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4D7Mh23fNXz3rvH X-Spamd-Bar: - X-Spamd-Result: default: False [-1.60 / 15.00]; HAS_REPLYTO(0.00)[junchoon@dec.sakura.ne.jp]; RCVD_VIA_SMTP_AUTH(0.00)[]; MV_CASE(0.50)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; TO_DN_NONE(0.00)[]; HAS_ORG_HEADER(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[210.188.226.8:from]; ASN(0.00)[asn:9370, ipnet:210.188.224.0/19, country:JP]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[115.38.187.204:received]; R_DKIM_NA(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[sakura.ne.jp]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[210.188.226.8:from:127.0.2.255]; RCVD_TLS_LAST(0.00)[]; R_SPF_NA(0.00)[no SPF record]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 02 Jan 2021 13:10:27 -0000 On Sat, 02 Jan 2021 09:47:07 +0100 "Herbert J. Skuhra" wrote: > On Sat, 02 Jan 2021 09:31:36 +0100, Graham Perrin wrote: > > > > With the transition to Git > > > > ========================== > > > > If it's true that /usr/src is _no longer_ a predictable path to the > > source files, then is it still appropriate for users' fortunes to > > include this FreeBSD tip? > > > > > > > > It is, still, essentially a smart tip (thank you, Lars) however some > > readers who have switched to the `git` approach might benefit from an > > additional hint to use option -s > > > > svnlite > > ======= > > > > > > still describes use of `svnlite` (not `git` or `got`) and, I guess, > > might continue to do so for some time. > > > > In this context, is `cd /usr/src` still true? > > If you clone the repository to /usr/src instead of e.g. > /usr/src/freebsd-current. I think cloning src tree into a subdirectory of /usr/src should be discouraged. Cloning into e.g. /usr/src-git/(branch) and make /usr/src a symlink (or hardlink) to whichever the branch to be built/installed would be better if you want to keep multiple branch. Of course, if you need only one branch (e.g. main) and want to follow existing official example, /usr/src is the only place to clone repo to. > > -- > Herbert > _______________________________________________ > 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" -- Tomoaki AOKI From owner-freebsd-current@freebsd.org Sat Jan 2 13:10:47 2021 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 C207E4CFA07 for ; Sat, 2 Jan 2021 13:10:47 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4D7MhQ49V8z3sKm for ; Sat, 2 Jan 2021 13:10:46 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from [188.174.60.30] (helo=c720-r368166.unixarea.de) by ms-10.1blu.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kvgg8-0000iU-2I; Sat, 02 Jan 2021 14:10:44 +0100 Received: from c720-r368166.fritz.box (localhost [127.0.0.1]) by c720-r368166.unixarea.de (8.16.1/8.14.9) with ESMTPS id 102DAgnH031629 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 2 Jan 2021 14:10:42 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by c720-r368166.fritz.box (8.16.1/8.14.9/Submit) id 102DAgDL031628; Sat, 2 Jan 2021 14:10:42 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: c720-r368166.fritz.box: guru set sender to guru@unixarea.de using -f Date: Sat, 2 Jan 2021 14:10:42 +0100 From: Matthias Apitz To: freebsd-current@freebsd.org Subject: moving /usr/src and /usr/obj to another machine for installation Message-ID: Reply-To: Matthias Apitz Mail-Followup-To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable X-Operating-System: FreeBSD 13.0-CURRENT r368166 (amd64) X-message-flag: Mails containing HTML will not be read! Please send only plain text. X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 188.174.60.30 X-Rspamd-Queue-Id: 4D7MhQ49V8z3sKm X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.20 / 15.00]; HAS_REPLYTO(0.00)[guru@unixarea.de]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_XOIP(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[178.254.4.101:from]; HAS_XAW(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RECEIVED_SPAMHAUS_PBL(0.00)[188.174.60.30:received]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[178.254.4.101:from]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:42730, ipnet:178.254.0.0/19, country:DE]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[unixarea.de]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[178.254.4.101:from:127.0.2.255]; RCVD_IN_DNSWL_LOW(-0.10)[178.254.4.101:from]; R_SPF_NA(0.00)[no SPF record]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 02 Jan 2021 13:10:47 -0000 Hello, I have a potent machine where I build my systems and ports with poudriere: [root@jet /usr/src]# uname -a FreeBSD jet 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r368166: Mon Nov 30 10:06:= 30 CET 2020 guru@jet:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 [root@jet /usr/src]# svn info Path: . Working Copy Root Path: /usr/src URL: svn://svn.freebsd.org/base/head Relative URL: ^/head Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 368166 Node Kind: directory Schedule: normal Last Changed Author: melifaro Last Changed Rev: 368164 Last Changed Date: 2020-11-29 20:43:33 +0100 (Sun, 29 Nov 2020) The kernel there is built and installed the normal way # make buildworld # make buildkernel KERNCONF=3DGENERIC =2E.. and it works fine (poudiere compiled ~2400 ports on it). My idea (and used procedure) in the past was: create a tar archive: # tar cfz r368166-src-obj.tgz /usr/src /usr/obj move the file r368166-src-obj.tgz to another small netbook and unpack it there with: [root@c720-r314251-vale /]# uname -a FreeBSD c720-r314251-vale 12.0-CURRENT FreeBSD 12.0-CURRENT #1 r314251M: Tu= e Apr 2 07:19:39 CEST 2019 guru@c720-r314251-vale:/usr/obj/usr/src/sys= /GENERIC amd64 [root@c720-r314251-vale /]# rm -rf /usr/src /usr/obj [root@c720-r314251-vale /]# cd / [root@c720-r314251-vale /]# tar xzf r368166-src-obj.tgz [root@c720-r314251-vale /]# cd /usr/src [root@c720-r314251-vale /usr/src]# svn info Path: . Working Copy Root Path: /usr/src URL: svn://svn.freebsd.org/base/head Relative URL: ^/head Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 368166 Node Kind: directory Schedule: normal Last Changed Author: melifaro Last Changed Rev: 368164 Last Changed Date: 2020-11-29 20:43:33 +0100 (Sun, 29 Nov 2020) And when I now want to recompile the kernel there (to fix a small bug related to the keyboard in /usr/src/sys/dev/atkbdc/atkbdc.c), this fails with [root@c720-r314251-vale /usr/src]# make buildkernel -DNO_CLEAN KERNCONF=3DG= ENERIC make[1]: "/usr/src/Makefile.inc1" line 341: SYSTEM_COMPILER: libclang will = be built for bootstrapping a cross-compiler. make[1]: "/usr/src/Makefile.inc1" line 346: SYSTEM_LINKER: libclang will be= built for bootstrapping a cross-linker. make[1]: "/usr/src/Makefile.inc1" line 454: The src.conf WITHOUT_CLEAN opti= on can now be used instead of NO_CLEAN. -------------------------------------------------------------- >>> Kernel build for GENERIC started on Sat Jan 2 13:35:31 CET 2021 -------------------------------------------------------------- =3D=3D=3D> GENERIC mkdir -p /usr/obj/usr/src/amd64.amd64/sys -------------------------------------------------------------- >>> stage 1: configuring the kernel -------------------------------------------------------------- cd /usr/src/sys/amd64/conf; PATH=3D/usr/obj/usr/src/amd64.amd64/tmp/bin:/u= sr/obj/usr/src/amd64.amd64/tmp/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/us= r/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/usr/src/amd= 64.amd64/tmp/legacy/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/bin:/us= r/obj/usr/src/amd64.amd64/tmp/legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr= /bin config -d /usr/obj/usr/src/amd64.amd64/sys/GENERIC -I '/usr/src/sys= /amd64/conf' -I '/usr/src/sys/amd64/conf' '/usr/src/sys/amd64/conf/GENERIC' Kernel build directory is /usr/obj/usr/src/amd64.amd64/sys/GENERIC Don't forget to do ``make cleandepend && make depend'' cd /usr/src; MACHINE_ARCH=3Damd64 MACHINE=3Damd64 CPUTYPE=3D CC=3D"cc -ta= rget x86_64-unknown-freebsd13.0 --sysroot=3D/usr/obj/usr/src/amd64.amd64/tm= p -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin" CXX=3D"c++ -target x86_64-un= known-freebsd13.0 --sysroot=3D/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/u= sr/src/amd64.amd64/tmp/usr/bin" CPP=3D"cpp -target x86_64-unknown-freebsd1= 3.0 --sysroot=3D/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.a= md64/tmp/usr/bin" AS=3D"as" AR=3D"ar" LD=3D"ld" LLVM_LINK=3D"" NM=3Dnm OB= JCOPY=3D"objcopy" RANLIB=3Dranlib STRINGS=3D SIZE=3D"size" STRIPBIN=3D"st= rip" INSTALL=3D"install -U" PATH=3D/usr/obj/usr/src/amd64.amd64/tmp/bin:/= usr/obj/usr/src/amd64.amd64/tmp/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/u= sr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/usr/src/am= d64.amd64/tmp/legacy/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/bin:/u= sr/obj/usr/src/amd64.amd64/tmp/legacy/usr/libexec::/sbin:/bin:/usr/sbin:/us= r/bin SYSROOT=3D/usr/obj/usr/src/amd64.amd64/tmp make -f Makefile.inc1 B= WPHASE=3Dbuildkernel DESTDIR=3D/usr/obj/usr/src/amd64.amd64/tmp _cleankern= obj_fast_depend_hack /usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin/make: Undefined symbol "re= addir" *** Error code 1 Stop. make[1]: stopped in /usr/src *** Error code 1 Stop. make: stopped in /usr/src Why this procedure does not work? The file above /usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin/make is really outdated: # ls -l /usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin/make -r-xr-xr-x 1 root wheel 195944 Feb 12 2020 /usr/obj/usr/src/amd64.amd64= /tmp/legacy/usr/sbin/make but it is also outdated on the source machine and in the tar file. Maybe on the source host (jet) the /usr/obj was not purged before. But why it does not hurt on the source host (I tested the same make buildkernel right now, works fine) and it does hurt on the second host? What is wrong with the above procedure? Thanks matthias --=20 Matthias Apitz, =E2=9C=89 guru@unixarea.de, http://www.unixarea.de/ +49-176= -38902045 Public GnuPG key: http://www.unixarea.de/key.pub =C2=A1Con Cuba no te metas! =C2=AB=C2=BB Don't mess with Cuba! =C2=AB=C2= =BB Leg Dich nicht mit Kuba an! http://www.cubadebate.cu/noticias/2020/12/25/en-video-con-cuba-no-te-metas/ From owner-freebsd-current@freebsd.org Sat Jan 2 14:59:16 2021 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 91B764D298F for ; Sat, 2 Jan 2021 14:59:16 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4D7Q5b6w39z4Tvv for ; Sat, 2 Jan 2021 14:59:15 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from [188.174.60.30] (helo=c720-r368166.unixarea.de) by ms-10.1blu.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kviN7-0007uK-R0 for freebsd-current@freebsd.org; Sat, 02 Jan 2021 15:59:13 +0100 Received: from c720-r368166.fritz.box (localhost [127.0.0.1]) by c720-r368166.unixarea.de (8.16.1/8.14.9) with ESMTPS id 102ExDh0039572 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Sat, 2 Jan 2021 15:59:13 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by c720-r368166.fritz.box (8.16.1/8.14.9/Submit) id 102ExCCV039571 for freebsd-current@freebsd.org; Sat, 2 Jan 2021 15:59:12 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: c720-r368166.fritz.box: guru set sender to guru@unixarea.de using -f Date: Sat, 2 Jan 2021 15:59:12 +0100 From: Matthias Apitz To: freebsd-current@freebsd.org Subject: cp(1) of large files is causing 100% CPU utilization and poor transfer Message-ID: Reply-To: Matthias Apitz Mail-Followup-To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Operating-System: FreeBSD 13.0-CURRENT r368166 (amd64) X-message-flag: Mails containing HTML will not be read! Please send only plain text. X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 188.174.60.30 X-Rspamd-Queue-Id: 4D7Q5b6w39z4Tvv X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.20 / 15.00]; HAS_REPLYTO(0.00)[guru@unixarea.de]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_XOIP(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[178.254.4.101:from]; HAS_XAW(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RECEIVED_SPAMHAUS_PBL(0.00)[188.174.60.30:received]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[178.254.4.101:from]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:42730, ipnet:178.254.0.0/19, country:DE]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[unixarea.de]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[178.254.4.101:from:127.0.2.255]; RCVD_IN_DNSWL_LOW(-0.10)[178.254.4.101:from]; R_SPF_NA(0.00)[no SPF record]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 02 Jan 2021 14:59:16 -0000 This is with: # uname -a FreeBSD c720-r368166 13.0-CURRENT FreeBSD 13.0-CURRENT #23 r368166M: Thu Dec 17 13:12:37 CET 2020 guru@c720-r368166:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 I copy often large backup files to an external USB disk and hit the following problem since updating to r368166: A transfer with dd(1) works fast and as expected (~70M / sec): # dd if=guru-20210102.tar.gz of=/mnt/AcerC720/backups/guru-20210102.tar.gz bs=8m 4601+1 records in 4601+1 records out 38603862368 bytes transferred in 506.778929 secs (76174956 bytes/sec) # ls -lh guru-20210102.tar.gz -r-------- 1 root wheel 36G 2 ene. 12:19 guru-20210102.tar.gz When I use cp(1) what I normaly do the transfer is very poor and causes 100% CPU itilization: # cp -p guru-20210102.tar.gz /mnt/AcerC720/backups/xxx ^C killed after 1 minute; transfered in 1 minute: # ls -lh /mnt/AcerC720/backups/xxx -r-------- 1 root wheel 168M 2 ene. 15:34 /mnt/AcerC720/backups/xxx 168*1024*1024/60 = 2936012 bytes/sec ./. 76174956 bytes/sec Trussing the cp(1) process shows these sys calls: # truss -p 37655 copy_file_range(0x3,0x0,0x4,0x0,0x200000,0x0) = 2097152 (0x200000) copy_file_range(0x3,0x0,0x4,0x0,0x200000,0x0) = 2097152 (0x200000) copy_file_range(0x3,0x0,0x4,0x0,0x200000,0x0) = 2097152 (0x200000) copy_file_range(0x3,0x0,0x4,0x0,0x200000,0x0) = 2097152 (0x200000) copy_file_range(0x3,0x0,0x4,0x0,0x200000,0x0) = 2097152 (0x200000) The problem is unrelated to the external disk, also a copy in the local file system shows the same transfer speed of 168M per minute. Is this a known issue or a regressionc ? I see in the man page of copy_file_range(2) that this is new with FreeBSD 13... matthias -- Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub ¡Con Cuba no te metas! «» Don't mess with Cuba! «» Leg Dich nicht mit Kuba an! http://www.cubadebate.cu/noticias/2020/12/25/en-video-con-cuba-no-te-metas/ From owner-freebsd-current@freebsd.org Sat Jan 2 15:18:23 2021 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 1FE654D35AD for ; Sat, 2 Jan 2021 15:18:23 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [18.222.6.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.soaustin.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D7QWf3WNpz4WBJ for ; Sat, 2 Jan 2021 15:18:22 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from lonesome.com (unknown [18.188.142.31]) by mail.soaustin.net (Postfix) with ESMTPSA id 8079D170FD; Sat, 2 Jan 2021 15:18:21 +0000 (UTC) Date: Sat, 2 Jan 2021 15:18:20 +0000 From: Mark Linimon To: grarpamp Cc: freebsd-current@freebsd.org Subject: Re: HEADS UP: FreeBSD src repo transitioning to git this weekend Message-ID: <20210102151819.GA30561@lonesome.com> References: <20201230004620.GB31099@funkthat.com> <20201231193908.GC31099@funkthat.com> <20210101140857.x3hbci6c4nwi7gl7@mutt-hbsd> <20210102021254.35o3snqb5fcvmbt3@mutt-hbsd> <60082.1609572957@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Rspamd-Queue-Id: 4D7QWf3WNpz4WBJ X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.20 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[18.222.6.11:from]; ASN(0.00)[asn:16509, ipnet:18.220.0.0/14, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[18.222.6.11:from]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[linimon]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[lonesome.com]; AUTH_NA(1.00)[]; SPAMHAUS_ZRD(0.00)[18.222.6.11:from:127.0.2.255]; R_DKIM_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; R_SPF_NA(0.00)[no SPF record]; 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.34 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, 02 Jan 2021 15:18:23 -0000 Folks, please change the Subject: line here. This has now become a thread of only tangiental interest to a typical FreeBSD developer (in this case, typified by me :-) ) mcl From owner-freebsd-current@freebsd.org Sat Jan 2 15:42:14 2021 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 EFDF64D413B for ; Sat, 2 Jan 2021 15:42:14 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oi1-f180.google.com (mail-oi1-f180.google.com [209.85.167.180]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D7R3B0VW9z4XNd for ; Sat, 2 Jan 2021 15:42:13 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-oi1-f180.google.com with SMTP id s2so27084075oij.2 for ; Sat, 02 Jan 2021 07:42:13 -0800 (PST) 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; bh=BI25AOzT9eC7cnSMObWaaokQg9GtJL7+4IWlO1t2BFQ=; b=WtYezzb4lxn5TYBzktVmQ7ySbo7nmzz6dPnayhXKjUCUfcfqJxlDPtqkF84PwwabQb kTEKlJDdTJUj9+xo/S1CWVMfN6pdg/VT7GLTc1M+yNh+Wp8jSs13phiF/61mHh2QCUsh /Gm0bQQGw/cGU2qiLPzB5JtKLG7RuP47P5HWZEMnp4eBplaSpeWRzfNeUCQCEsqtTQNC aaiFL3CC/Xz6VkW17mruueeKsfvnER4iZYq8ayjivaFJWstLhz7kUBzPDjFVrHuauFOr bhHFzsrS27nmts/cJTKGXacqYQBIYdWx5J4YhVF1Lp7kdk2WGFxrZhIdAkKPo8+QV7Bk WDxg== X-Gm-Message-State: AOAM530dflTUD2YS2RxzEOETUQlMbk09XshMyt0dIV/6i5Nz6t4OyDmQ axDB8NrJjcGZ0++iROdWmOE14G6o/2ZW5tEDP5dbeHzcO9TaBw== X-Google-Smtp-Source: ABdhPJxd7bnnd3HLLJzF3C+uHKBtbT7+j9I/EbeTWPvxhXkEkJrFiTcxeuCWYpyB1z3F2U3j0fzhAQRbJMKTkrxLpbg= X-Received: by 2002:aca:dd09:: with SMTP id u9mr13477373oig.73.1609602132873; Sat, 02 Jan 2021 07:42:12 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Alan Somers Date: Sat, 2 Jan 2021 08:42:01 -0700 Message-ID: Subject: Re: cp(1) of large files is causing 100% CPU utilization and poor transfer To: Matthias Apitz , FreeBSD CURRENT X-Rspamd-Queue-Id: 4D7R3B0VW9z4XNd X-Spamd-Bar: -- X-Spamd-Result: default: False [-3.00 / 15.00]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RBL_DBL_DONT_QUERY_IPS(0.00)[209.85.167.180:from]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[asomers]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; R_DKIM_NA(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; SPAMHAUS_ZRD(0.00)[209.85.167.180:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[209.85.167.180:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.167.180: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.34 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 02 Jan 2021 15:42:15 -0000 On Sat, Jan 2, 2021 at 7:59 AM Matthias Apitz wrote: > > This is with: > > # uname -a > FreeBSD c720-r368166 13.0-CURRENT FreeBSD 13.0-CURRENT #23 r368166M: Thu > Dec 17 13:12:37 CET 2020 guru@c720-r368166:/usr/obj/usr/src/amd64.amd64/sys/GENERIC > amd64 > > I copy often large backup files to an external USB disk and hit the > following problem since updating to r368166: > > A transfer with dd(1) works fast and as expected (~70M / sec): > > # dd if=guru-20210102.tar.gz of=/mnt/AcerC720/backups/guru-20210102.tar.gz > bs=8m > 4601+1 records in > 4601+1 records out > 38603862368 bytes transferred in 506.778929 secs (76174956 bytes/sec) > # ls -lh guru-20210102.tar.gz > -r-------- 1 root wheel 36G 2 ene. 12:19 guru-20210102.tar.gz > > When I use cp(1) what I normaly do the transfer is very poor and causes > 100% CPU itilization: > > # cp -p guru-20210102.tar.gz /mnt/AcerC720/backups/xxx > ^C > > killed after 1 minute; transfered in 1 minute: > > # ls -lh /mnt/AcerC720/backups/xxx > -r-------- 1 root wheel 168M 2 ene. 15:34 /mnt/AcerC720/backups/xxx > > 168*1024*1024/60 = 2936012 bytes/sec ./. 76174956 bytes/sec > > Trussing the cp(1) process shows these sys calls: > > # truss -p 37655 > copy_file_range(0x3,0x0,0x4,0x0,0x200000,0x0) = 2097152 (0x200000) > copy_file_range(0x3,0x0,0x4,0x0,0x200000,0x0) = 2097152 (0x200000) > copy_file_range(0x3,0x0,0x4,0x0,0x200000,0x0) = 2097152 (0x200000) > copy_file_range(0x3,0x0,0x4,0x0,0x200000,0x0) = 2097152 (0x200000) > copy_file_range(0x3,0x0,0x4,0x0,0x200000,0x0) = 2097152 (0x200000) > > The problem is unrelated to the external disk, also a copy > in the local file system shows the same transfer speed of 168M per > minute. > > Is this a known issue or a regressionc ? > > I see in the man page of copy_file_range(2) that this is new with > FreeBSD 13... > > matthias > Not an issue I've heard of before. Could you please describe how your USB and local disk are formatted? Also, where is the source file stored? It could be that the source file's file system has a very slow implementation of FIOSEEKDATA/FIOSEEKHOLE. -Alan From owner-freebsd-current@freebsd.org Sat Jan 2 15:43:08 2021 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 6DB5D4D42BE for ; Sat, 2 Jan 2021 15:43:08 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D7R4C5Cvsz4XjX for ; Sat, 2 Jan 2021 15:43:07 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: by mail-wr1-x435.google.com with SMTP id w5so26593175wrm.11 for ; Sat, 02 Jan 2021 07:43:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=0xuTKsnx7i1DmgIl7+F51hJiM+H9fAvi/rLQ1oMCWFk=; b=lNQ34IaLrRFCIFO/DP6ZEqU1Q9TfNcm0b8cotfviyllR+tZjbIG2oSqwWmJI6rpImy 694InZQJMDotnOILFKdxU549zhlIkNrXFLLe2tzmf1R4xPd94u7ZddC65qds+j9krlsd OuYESg9j7K84f9FdgR0OjNvPV0ITNVeuVXcqjB5gKGLVcR9vqPm3UsFPZv3cQrrdlmww UIB4L6f0dBaew5sHQJ3PLL43/k+DQp8vyixnyEgm8pVyI3Pwmwgs4MBva/rZVkOZTcxw q9sfApZpXzm14czsEEMSwb8yW5jXwCT2hPSYhMXd/JbGgHLyDzq9vN1Jg6PHUxpglYp2 wAXA== X-Gm-Message-State: AOAM531TDxC6rXoiNtCLKbAjvzupIhJw57lxrABzKPMjKrBzu7jZV+YB VFfS42ESBgpf7hgb+tIrPUoVJijnGO1mcg== X-Google-Smtp-Source: ABdhPJwNuyVZwJiJNp6ovWAT1wbZrbTqYVhqSKXtFW+jTzhyira7mLjTtYEvZzegv79qSVW7eFnU8A== X-Received: by 2002:a05:6000:10c4:: with SMTP id b4mr73968400wrx.170.1609602185844; Sat, 02 Jan 2021 07:43:05 -0800 (PST) Received: from [192.168.1.11] (79-66-147-78.dynamic.dsl.as9105.com. [79.66.147.78]) by smtp.gmail.com with ESMTPSA id s1sm82222678wrv.97.2021.01.02.07.43.05 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 02 Jan 2021 07:43:05 -0800 (PST) Subject: Re: etcupdate, svnlite, documentation etc. following the transition of source to Git To: FreeBSD CURRENT References: <87lfdctq83.wl-herbert@gojira.at> <87pn2nu3n8.wl-herbert@gojira.at> From: Graham Perrin Message-ID: <1d6c0954-ca13-b3a0-3e82-c79df594e357@gmail.com> Date: Sat, 2 Jan 2021 15:43:04 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <87pn2nu3n8.wl-herbert@gojira.at> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB X-Rspamd-Queue-Id: 4D7R4C5Cvsz4XjX X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RECEIVED_SPAMHAUS_PBL(0.00)[79.66.147.78:received]; FROM_EQ_ENVFROM(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a00:1450:4864:20::435:from]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[2a00:1450:4864:20::435:from:127.0.2.255]; MIME_TRACE(0.00)[0:+]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::435:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 02 Jan 2021 15:43:08 -0000 On 02/01/2021 08:47, Herbert J. Skuhra wrote: >> >> still describes use of `svnlite` (not `git` or `got`) and, I guess, >> might continue to do so for some time. >> >> In this context, is `cd /usr/src` still true? > If you clone the repository to /usr/src instead of e.g. > /usr/src/freebsd-current. Thanks again. I imagine that use cases will _eventually_ include trios of directories, as siblings, for example: /usr/src/doc /usr/src/freebsd-stable /usr/src/ports True: there's the tradition of /usr/ports however with all three things moved, or moving, to Git it seems (to me) sensible to have the source files for ports at /usr/src/ports For consistency. A cohesive approach. From owner-freebsd-current@freebsd.org Sat Jan 2 15:54:03 2021 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 9A6AB4D48B6 for ; Sat, 2 Jan 2021 15:54:03 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from mx.catwhisker.org (mx.catwhisker.org [107.204.234.170]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4D7RJp2BQKz4YY1 for ; Sat, 2 Jan 2021 15:54:02 +0000 (UTC) (envelope-from david@catwhisker.org) Received: from albert.catwhisker.org (localhost [127.0.0.1]) by albert.catwhisker.org (8.16.1/8.15.2) with ESMTP id 102Frs5D086327; Sat, 2 Jan 2021 15:53:54 GMT (envelope-from david@albert.catwhisker.org) Received: (from david@localhost) by albert.catwhisker.org (8.16.1/8.16.1/Submit) id 102FrskH086325; Sat, 2 Jan 2021 07:53:54 -0800 (PST) (envelope-from david) Date: Sat, 2 Jan 2021 07:53:54 -0800 From: David Wolfskill To: Graham Perrin Cc: FreeBSD CURRENT Subject: Re: etcupdate, svnlite, documentation etc. following the transition of source to Git Message-ID: Reply-To: current@freebsd.org Mail-Followup-To: current@freebsd.org, Graham Perrin , FreeBSD CURRENT References: <87lfdctq83.wl-herbert@gojira.at> <87pn2nu3n8.wl-herbert@gojira.at> <1d6c0954-ca13-b3a0-3e82-c79df594e357@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="h9KRLD9xw7xh/Fon" Content-Disposition: inline In-Reply-To: <1d6c0954-ca13-b3a0-3e82-c79df594e357@gmail.com> X-Rspamd-Queue-Id: 4D7RJp2BQKz4YY1 X-Spamd-Bar: ----- X-Spamd-Result: default: False [-5.40 / 15.00]; HAS_REPLYTO(0.00)[current@freebsd.org]; RBL_DBL_DONT_QUERY_IPS(0.00)[107.204.234.170:from]; FREEFALL_USER(0.00)[david]; FROM_HAS_DN(0.00)[]; SIGNED_PGP(-2.00)[]; R_SPF_ALLOW(-0.20)[+ip4:107.204.234.170]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; REPLYTO_DOM_NEQ_FROM_DOM(0.00)[]; ARC_NA(0.00)[]; DMARC_NA(0.00)[catwhisker.org]; SPAMHAUS_ZRD(0.00)[107.204.234.170:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; RCVD_TLS_LAST(0.00)[]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:7018, ipnet:107.192.0.0/12, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 02 Jan 2021 15:54:03 -0000 --h9KRLD9xw7xh/Fon Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jan 02, 2021 at 03:43:04PM +0000, Graham Perrin wrote: > ... > >> In this context, is `cd /usr/src` still true? > > If you clone the repository to /usr/src instead of e.g. > > /usr/src/freebsd-current. >=20 > Thanks again. >=20 > I imagine that use cases will _eventually_ include trios of directories,= =20 > as siblings, for example: >=20 > /usr/src/doc /usr/src/freebsd-stable >=20 > /usr/src/ports Please see hier(7). The default (and expected) location of a given part of the tree (such as sources residing in /usr/src/ and ports in /usr/ports/) is based on their function, not on the mechanism used to update/maintain those files -- which is completely orthogonal to the location. > True: there's the tradition of /usr/ports As documented in hier(7). > however with all three things moved, or moving, to Git it seems (to me)= =20 > sensible to have the source files for ports at >=20 > /usr/src/ports >=20 > For consistency. A cohesive approach. > ... Not on any machine where I decide where things go. You're free to do that, but IMO, you're setting yourself up for toe-stubbing and confusion if you do. > .... Peace, david --=20 David H. Wolfskill david@catwhisker.org My concern about US "election integrity" is about the attacks on that integrity from members of the party of Senator Hawley -- especially Trump. See https://www.catwhisker.org/~david/publickey.gpg for my public key. --h9KRLD9xw7xh/Fon Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAEBCgB9FiEE4owz2QxMJyaxAefyQLJg+bY2PckFAl/wlxJfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEUy OEMzM0Q5MEM0QzI3MjZCMTAxRTdGMjQwQjI2MEY5QjYzNjNEQzkACgkQQLJg+bY2 PclDRQgArBRMr3g29tt3sgNs7gpO++bQiwkJhG3YhI1NY0uC1rwr0hKUEzYebKUS 63J9YKauAsjkqkixU473hAjU0oYeWbVH0moSOJ0DphaZU+FcBHcd2sJxuqiDp8bq drCTbrMnlcF4WI/al+FdkRaDNEbnoTGwCZtDQZRp+M6LS8jYGF5TAtfUNurMarvv 2W+gxHtxcxVBSIJdnTmzL2LG68ULVElvwBFEUDjhY6aTRTi++xzFO+vJOJrpeDaS 85YpWWTPOwjm23ZXElGwL3oIJ3zHafOFus5J5elyLH1K0mjGWHcAlHtaNbKuWxTz uH7Ej0yythIJ03zGCHGwDihbPkTSxw== =64Tk -----END PGP SIGNATURE----- --h9KRLD9xw7xh/Fon-- From owner-freebsd-current@freebsd.org Sat Jan 2 16:02:11 2021 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 067584D4F05 for ; Sat, 2 Jan 2021 16:02:11 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4D7RVB15Y4z4Z59; Sat, 2 Jan 2021 16:02:09 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from [188.174.60.30] (helo=c720-r368166.unixarea.de) by ms-10.1blu.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kvjLz-0006Qz-Ti; Sat, 02 Jan 2021 17:02:08 +0100 Received: from c720-r368166.fritz.box (localhost [127.0.0.1]) by c720-r368166.unixarea.de (8.16.1/8.14.9) with ESMTPS id 102G26ZY044591 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 2 Jan 2021 17:02:06 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by c720-r368166.fritz.box (8.16.1/8.14.9/Submit) id 102G26xu044590; Sat, 2 Jan 2021 17:02:06 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: c720-r368166.fritz.box: guru set sender to guru@unixarea.de using -f Date: Sat, 2 Jan 2021 17:02:06 +0100 From: Matthias Apitz To: Alan Somers Cc: FreeBSD CURRENT Subject: Re: cp(1) of large files is causing 100% CPU utilization and poor transfer Message-ID: Reply-To: Matthias Apitz Mail-Followup-To: Alan Somers , FreeBSD CURRENT References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: FreeBSD 13.0-CURRENT r368166 (amd64) X-message-flag: Mails containing HTML will not be read! Please send only plain text. X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 188.174.60.30 X-Rspamd-Queue-Id: 4D7RVB15Y4z4Z59 X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.20 / 15.00]; HAS_REPLYTO(0.00)[guru@unixarea.de]; RCVD_VIA_SMTP_AUTH(0.00)[]; HAS_XOIP(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[178.254.4.101:from]; HAS_XAW(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RCPT_COUNT_TWO(0.00)[2]; RECEIVED_SPAMHAUS_PBL(0.00)[188.174.60.30:received]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[178.254.4.101:from]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:42730, ipnet:178.254.0.0/19, country:DE]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[unixarea.de]; AUTH_NA(1.00)[]; SPAMHAUS_ZRD(0.00)[178.254.4.101:from:127.0.2.255]; RCVD_IN_DNSWL_LOW(-0.10)[178.254.4.101:from]; R_SPF_NA(0.00)[no SPF record]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 02 Jan 2021 16:02:11 -0000 El día sábado, enero 02, 2021 a las 08:42:01a. m. -0700, Alan Somers escribió: > > # dd if=guru-20210102.tar.gz of=/mnt/AcerC720/backups/guru-20210102.tar.gz > > bs=8m > > 4601+1 records in > > 4601+1 records out > > 38603862368 bytes transferred in 506.778929 secs (76174956 bytes/sec) > > # ls -lh guru-20210102.tar.gz > > -r-------- 1 root wheel 36G 2 ene. 12:19 guru-20210102.tar.gz > > > > When I use cp(1) what I normaly do the transfer is very poor and causes > > 100% CPU itilization: > > > > # cp -p guru-20210102.tar.gz /mnt/AcerC720/backups/xxx > > ^C > > > > killed after 1 minute; transfered in 1 minute: > > > > # ls -lh /mnt/AcerC720/backups/xxx > > -r-------- 1 root wheel 168M 2 ene. 15:34 /mnt/AcerC720/backups/xxx > > > > 168*1024*1024/60 = 2936012 bytes/sec ./. 76174956 bytes/sec > > > > Trussing the cp(1) process shows these sys calls: > > > > # truss -p 37655 > > copy_file_range(0x3,0x0,0x4,0x0,0x200000,0x0) = 2097152 (0x200000) > > copy_file_range(0x3,0x0,0x4,0x0,0x200000,0x0) = 2097152 (0x200000) > > copy_file_range(0x3,0x0,0x4,0x0,0x200000,0x0) = 2097152 (0x200000) > > copy_file_range(0x3,0x0,0x4,0x0,0x200000,0x0) = 2097152 (0x200000) > > copy_file_range(0x3,0x0,0x4,0x0,0x200000,0x0) = 2097152 (0x200000) > > > > The problem is unrelated to the external disk, also a copy > > in the local file system shows the same transfer speed of 168M per > > minute. > Not an issue I've heard of before. Could you please describe how your USB > and local disk are formatted? Also, where is the source file stored? It > could be that the source file's file system has a very slow implementation > of FIOSEEKDATA/FIOSEEKHOLE. > -Alan As I said, it can be reproduced using only the local file system. This was setup recently on a SSD: # dmesg | grep ada0 ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ACS-2 ATA SATA 3.x device ada0: Serial Number F995890846 ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 1024bytes) ada0: Command Queueing enabled ada0: 488386MB (1000215216 512 byte sectors) and by this procedure: # gpart create -s gpt ada0 # gpart add -t freebsd-boot -s 512k -a4k -l ssdboot ada0 # gpart bootcode -b /boot/pmbr -p /boot/gptboot -i1 ada0 # gpart add -t freebsd-ufs -l ssdrootfs -b 1m -s 2g ada0 # gpart add -t freebsd-ufs -l ssdvarfs -a 1m -s 2g ada0 # gpart add -t freebsd-ufs -l ssdusrfs -a 1m ada0 # newfs -U -t /dev/gpt/ssdrootfs # newfs -U -t /dev/gpt/ssdvarfs # newfs -U -t /dev/gpt/ssdusrfs # gpart show -l ada0 => 40 1000215136 ada0 GPT (477G) 40 1024 1 ssdboot (512K) 1064 984 - free - (492K) 2048 4194304 2 ssdrootfs (2.0G) 4196352 4194304 3 ssdvarfs (2.0G) 8390656 16777216 4 ssdswap (8.0G) 25167872 975046656 5 ssdusrfs (465G) 1000214528 648 - free - (324K) # mount -t ufs /dev/gpt/ssdrootfs on / (ufs, local, soft-updates) /dev/gpt/ssdvarfs on /var (ufs, local, soft-updates) /dev/gpt/ssdusrfs on /usr (ufs, local, soft-updates) When I run in the /usr fs the command # cp -p guru-20210102.tar.gz xxx it copies around 168M per minute. matthias -- Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub ¡Con Cuba no te metas! «» Don't mess with Cuba! «» Leg Dich nicht mit Kuba an! http://www.cubadebate.cu/noticias/2020/12/25/en-video-con-cuba-no-te-metas/ From owner-freebsd-current@freebsd.org Sat Jan 2 16:06:38 2021 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 020884D4F4B for ; Sat, 2 Jan 2021 16:06:38 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oi1-f171.google.com (mail-oi1-f171.google.com [209.85.167.171]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D7RbJ6vlzz4Z41; Sat, 2 Jan 2021 16:06:36 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-oi1-f171.google.com with SMTP id s2so27127451oij.2; Sat, 02 Jan 2021 08:06:36 -0800 (PST) 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; bh=Zf4MuNf2zgrISUPUo2noalj0Ny+1qvujTDMcAMqDUHU=; b=miUPsrwZoZ8c8m7Lh6SWlZXW2ONlCINsno0jdz1PQASqaDLnad15/EJo4spqeNRwSI ZMv+oQQ81B1BnXoKyzUrDv3PIOEjDgw/Ibaf+npsEUud8Sjdmh+pk2D1xOgQOm4Gi3Tv CoVNHZrCYNkzHLdFBqgYOUBYN8lvdqfFDJDRIXcg7bOtjgCHFw9Xecv+qDosvYNdrl4G G1VjfeuqqEvI9fB7+NNqAWk3kou42s4JwLyL9CEfTHyIIxopYRuGdInROY4WZWLyzK0Z pyTmB7sI8mbJTLN3JOBP6ponwKlmVGQ0TURk4f6XowV2UfTvSahPM14DTmTQLInh9fyo b9Eg== X-Gm-Message-State: AOAM532zgEoBXEwzrsr8ovcuOEjqaPQ0XC/SOb7utvU+0tASr+ysHBqR BuSNTAnv8N3wQdGcp6mc19miekGqlMk/qQT83Og= X-Google-Smtp-Source: ABdhPJwU4thJCMCc9SHOuvnFTGuacIIJrKe82H9moD0qF0+/LQ7BTBrHfqVrgCbhmDnhQdmMAflfaqckSwlwiAnQDoM= X-Received: by 2002:aca:af8f:: with SMTP id y137mr13730485oie.55.1609603595768; Sat, 02 Jan 2021 08:06:35 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Alan Somers Date: Sat, 2 Jan 2021 09:06:24 -0700 Message-ID: Subject: Re: cp(1) of large files is causing 100% CPU utilization and poor transfer To: Matthias Apitz , Alan Somers , FreeBSD CURRENT X-Rspamd-Queue-Id: 4D7RbJ6vlzz4Z41 X-Spamd-Bar: - X-Spamd-Result: default: False [-1.26 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FREEFALL_USER(0.00)[asomers]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_NA(0.00)[freebsd.org]; RBL_DBL_DONT_QUERY_IPS(0.00)[209.85.167.171:from]; NEURAL_SPAM_SHORT(0.74)[0.745]; SPAMHAUS_ZRD(0.00)[209.85.167.171:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[209.85.167.171:from]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.167.171:from]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; MAILMAN_DEST(0.00)[freebsd-current] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 02 Jan 2021 16:06:38 -0000 On Sat, Jan 2, 2021 at 9:02 AM Matthias Apitz wrote: > El d=C3=ADa s=C3=A1bado, enero 02, 2021 a las 08:42:01a. m. -0700, Alan S= omers > escribi=C3=B3: > > > > # dd if=3Dguru-20210102.tar.gz > of=3D/mnt/AcerC720/backups/guru-20210102.tar.gz > > > bs=3D8m > > > 4601+1 records in > > > 4601+1 records out > > > 38603862368 bytes transferred in 506.778929 secs (76174956 bytes/sec) > > > # ls -lh guru-20210102.tar.gz > > > -r-------- 1 root wheel 36G 2 ene. 12:19 guru-20210102.tar.gz > > > > > > When I use cp(1) what I normaly do the transfer is very poor and caus= es > > > 100% CPU itilization: > > > > > > # cp -p guru-20210102.tar.gz /mnt/AcerC720/backups/xxx > > > ^C > > > > > > killed after 1 minute; transfered in 1 minute: > > > > > > # ls -lh /mnt/AcerC720/backups/xxx > > > -r-------- 1 root wheel 168M 2 ene. 15:34 > /mnt/AcerC720/backups/xxx > > > > > > 168*1024*1024/60 =3D 2936012 bytes/sec ./. 76174956 bytes/sec > > > > > > Trussing the cp(1) process shows these sys calls: > > > > > > # truss -p 37655 > > > copy_file_range(0x3,0x0,0x4,0x0,0x200000,0x0) =3D 2097152 (0x20000= 0) > > > copy_file_range(0x3,0x0,0x4,0x0,0x200000,0x0) =3D 2097152 (0x20000= 0) > > > copy_file_range(0x3,0x0,0x4,0x0,0x200000,0x0) =3D 2097152 (0x20000= 0) > > > copy_file_range(0x3,0x0,0x4,0x0,0x200000,0x0) =3D 2097152 (0x20000= 0) > > > copy_file_range(0x3,0x0,0x4,0x0,0x200000,0x0) =3D 2097152 (0x20000= 0) > > > > > > The problem is unrelated to the external disk, also a copy > > > in the local file system shows the same transfer speed of 168M per > > > minute. > > > Not an issue I've heard of before. Could you please describe how your > USB > > and local disk are formatted? Also, where is the source file stored? = It > > could be that the source file's file system has a very slow > implementation > > of FIOSEEKDATA/FIOSEEKHOLE. > > -Alan > > > As I said, it can be reproduced using only the local file system. This > was setup recently on a SSD: > > # dmesg | grep ada0 > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > ada0: ACS-2 ATA SATA 3.x device > ada0: Serial Number F995890846 > ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 1024bytes) > ada0: Command Queueing enabled > ada0: 488386MB (1000215216 512 byte sectors) > > and by this procedure: > > # gpart create -s gpt ada0 > # gpart add -t freebsd-boot -s 512k -a4k -l ssdboot ada0 > # gpart bootcode -b /boot/pmbr -p /boot/gptboot -i1 ada0 > # gpart add -t freebsd-ufs -l ssdrootfs -b 1m -s 2g ada0 > # gpart add -t freebsd-ufs -l ssdvarfs -a 1m -s 2g ada0 > # gpart add -t freebsd-ufs -l ssdusrfs -a 1m ada0 > # newfs -U -t /dev/gpt/ssdrootfs > # newfs -U -t /dev/gpt/ssdvarfs > # newfs -U -t /dev/gpt/ssdusrfs > > # gpart show -l ada0 > =3D> 40 1000215136 ada0 GPT (477G) > 40 1024 1 ssdboot (512K) > 1064 984 - free - (492K) > 2048 4194304 2 ssdrootfs (2.0G) > 4196352 4194304 3 ssdvarfs (2.0G) > 8390656 16777216 4 ssdswap (8.0G) > 25167872 975046656 5 ssdusrfs (465G) > 1000214528 648 - free - (324K) > > # mount -t ufs > /dev/gpt/ssdrootfs on / (ufs, local, soft-updates) > /dev/gpt/ssdvarfs on /var (ufs, local, soft-updates) > /dev/gpt/ssdusrfs on /usr (ufs, local, soft-updates) > > When I run in the /usr fs the command > > # cp -p guru-20210102.tar.gz xxx > > it copies around 168M per minute. > > matthias > Is that copying from /usr to /usr, or from /usr to /var or /? From owner-freebsd-current@freebsd.org Sat Jan 2 16:12:04 2021 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 74A354D5817 for ; Sat, 2 Jan 2021 16:12:04 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4D7Rjc2swMz4ZZ7; Sat, 2 Jan 2021 16:12:04 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from [188.174.60.30] (helo=c720-r368166.unixarea.de) by ms-10.1blu.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kvjVa-0004UJ-Uv; Sat, 02 Jan 2021 17:12:03 +0100 Received: from c720-r368166.fritz.box (localhost [127.0.0.1]) by c720-r368166.unixarea.de (8.16.1/8.14.9) with ESMTPS id 102GC2Dd045508 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 2 Jan 2021 17:12:02 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by c720-r368166.fritz.box (8.16.1/8.14.9/Submit) id 102GC23L045507; Sat, 2 Jan 2021 17:12:02 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: c720-r368166.fritz.box: guru set sender to guru@unixarea.de using -f Date: Sat, 2 Jan 2021 17:12:02 +0100 From: Matthias Apitz To: Alan Somers Cc: FreeBSD CURRENT Subject: Re: cp(1) of large files is causing 100% CPU utilization and poor transfer Message-ID: Reply-To: Matthias Apitz Mail-Followup-To: Alan Somers , FreeBSD CURRENT References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: FreeBSD 13.0-CURRENT r368166 (amd64) X-message-flag: Mails containing HTML will not be read! Please send only plain text. X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 188.174.60.30 X-Rspamd-Queue-Id: 4D7Rjc2swMz4ZZ7 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 02 Jan 2021 16:12:04 -0000 El día sábado, enero 02, 2021 a las 09:06:24a. m. -0700, Alan Somers escribió: > > As I said, it can be reproduced using only the local file system. This > > was setup recently on a SSD: > > > > # dmesg | grep ada0 > > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > > ada0: ACS-2 ATA SATA 3.x device > > ada0: Serial Number F995890846 > > ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 1024bytes) > > ada0: Command Queueing enabled > > ada0: 488386MB (1000215216 512 byte sectors) > > > > and by this procedure: > > > > # gpart create -s gpt ada0 > > # gpart add -t freebsd-boot -s 512k -a4k -l ssdboot ada0 > > # gpart bootcode -b /boot/pmbr -p /boot/gptboot -i1 ada0 > > # gpart add -t freebsd-ufs -l ssdrootfs -b 1m -s 2g ada0 > > # gpart add -t freebsd-ufs -l ssdvarfs -a 1m -s 2g ada0 > > # gpart add -t freebsd-ufs -l ssdusrfs -a 1m ada0 > > # newfs -U -t /dev/gpt/ssdrootfs > > # newfs -U -t /dev/gpt/ssdvarfs > > # newfs -U -t /dev/gpt/ssdusrfs > > > > # gpart show -l ada0 > > => 40 1000215136 ada0 GPT (477G) > > 40 1024 1 ssdboot (512K) > > 1064 984 - free - (492K) > > 2048 4194304 2 ssdrootfs (2.0G) > > 4196352 4194304 3 ssdvarfs (2.0G) > > 8390656 16777216 4 ssdswap (8.0G) > > 25167872 975046656 5 ssdusrfs (465G) > > 1000214528 648 - free - (324K) > > > > # mount -t ufs > > /dev/gpt/ssdrootfs on / (ufs, local, soft-updates) > > /dev/gpt/ssdvarfs on /var (ufs, local, soft-updates) > > /dev/gpt/ssdusrfs on /usr (ufs, local, soft-updates) > > > > When I run in the /usr fs the command > > > > # cp -p guru-20210102.tar.gz xxx > > > > it copies around 168M per minute. > > > Is that copying from /usr to /usr, or from /usr to /var or /? # cd /home/backups # cp -p guru-20210102.tar.gz xxx i.e. from /usr to /usr. matthias -- Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub ¡Con Cuba no te metas! «» Don't mess with Cuba! «» Leg Dich nicht mit Kuba an! http://www.cubadebate.cu/noticias/2020/12/25/en-video-con-cuba-no-te-metas/ From owner-freebsd-current@freebsd.org Sat Jan 2 16:18:14 2021 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 011F74D5C1A for ; Sat, 2 Jan 2021 16:18:14 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D7Rrj1pWLz4b7l for ; Sat, 2 Jan 2021 16:18:12 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: by mail-wr1-x431.google.com with SMTP id t30so26704544wrb.0 for ; Sat, 02 Jan 2021 08:18:12 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=m1tSK/yLNBvJcd8zKxwzeTfMx/LuhC+jZ8i8S0eoR4k=; b=qGJ56gicwmbYUHFN6W1CEFQ7c5LQwNau+7WvTeFn+eFd4pGLH5PTPFzJyd9RRxZP92 +BKTaPHeltGLF3bHDD/nl+kBlnxj6fvLQudjst1qvpI5I4QX3rwwcxtsUs4a4Y5AOHKD YfYmpydIy6+xOll5QuVNtc9oCd8bIG9pDwMOkE1ycv7ys1qk+mePoyc/JQPH+x8xqqiq XJfFJYPfOez4CIeZamfPJg0l9LXwVXVG0Iw3oxzCVklfpA7o6ivVoZDj6IsaOuQai5JT vl6DViv4sfETYqgvSBgUs2RTzbpMPiM6d0D0SzyIHKo/4hJNzhHfg2VOM/NFedBIUyJ9 59Qw== X-Gm-Message-State: AOAM5319JUvZC12a9nJOMJUnlGZhZTh1bW2gXxeFTWn/9SRMdaoExieC QyD8Z2i+ARrtBYJOiCMnBuwRjQ1M2cpvKA== X-Google-Smtp-Source: ABdhPJxunSc8hdXr9QDP0C7txSMKUjqXX+GImY+G7HyNEsre/xau1nm8b0Ez114abKXHanoSSDAr6Q== X-Received: by 2002:a5d:4f0e:: with SMTP id c14mr72648545wru.84.1609604291484; Sat, 02 Jan 2021 08:18:11 -0800 (PST) Received: from [192.168.1.11] (79-66-147-78.dynamic.dsl.as9105.com. [79.66.147.78]) by smtp.gmail.com with ESMTPSA id a13sm76399701wrt.96.2021.01.02.08.18.10 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 02 Jan 2021 08:18:10 -0800 (PST) Subject: Re: etcupdate, svnlite, documentation etc. following the transition of source to Git From: Graham Perrin To: FreeBSD CURRENT References: <87lfdctq83.wl-herbert@gojira.at> <87pn2nu3n8.wl-herbert@gojira.at> <1d6c0954-ca13-b3a0-3e82-c79df594e357@gmail.com> Message-ID: Date: Sat, 2 Jan 2021 16:18:10 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <1d6c0954-ca13-b3a0-3e82-c79df594e357@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB X-Rspamd-Queue-Id: 4D7Rrj1pWLz4b7l X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a00:1450:4864:20::431:from]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; RECEIVED_SPAMHAUS_PBL(0.00)[79.66.147.78:received]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[2a00:1450:4864:20::431:from:127.0.2.255]; NEURAL_SPAM_SHORT(1.00)[0.998]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::431:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 02 Jan 2021 16:18:14 -0000 Sorry for the mis-formatting and lost line breaks in my previous e-mail. Blame Thunderbird. As reference: /usr/src > BSD, third-party, and/or local source files From owner-freebsd-current@freebsd.org Sat Jan 2 16:30:26 2021 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 DEA644D5D7C for ; Sat, 2 Jan 2021 16:30:26 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oi1-f172.google.com (mail-oi1-f172.google.com [209.85.167.172]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D7S6n6HHjz4bXt for ; Sat, 2 Jan 2021 16:30:25 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-oi1-f172.google.com with SMTP id q25so27143880oij.10 for ; Sat, 02 Jan 2021 08:30:25 -0800 (PST) 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; bh=jnASg1NwfgO9GfApxTvZ2HBmLhhsqOBkSo/9r1W3fqo=; b=B5J74tzSBCtKxTb58cgKZl5DE//WxTtMZSXt2eO2HK0l1SPJKOMHh2BfQ7fL58qHD2 igfr8szsYU/Bm1P8cCnd08Pqs+xOvPVaNgsl2cjgELwQTmtSKpBtMcw02Yxr0hI+xtVH kLRF41E+XcMulyAfzbb9LBrrvsNtHYFlXMZBKLIoTISzIVlGpXC0jg2ggKPFmTmpTCFB n8ln3Lj2R+aq3+VAktdL8gjewP7PtuRWwQlVpviWzpqvVDr6bLwFT0GT8hChiqRnkxlW D4qrnEfTyTDowY57rABK4bbbwFp/J3LVU4V9mHFRjKZmbA8j9z9diOr7aRx+JUUu/8ub xdXg== X-Gm-Message-State: AOAM531NEqvwyaAPyW9NA9IXFX+ZYKKTBDdWeJa3KEf7t5/P4hGEq371 7W0BarCTdbZx3BF8DeUZ03u4ou4852C/qXOHhMI= X-Google-Smtp-Source: ABdhPJziS9I4LRROjiYSqXFWmvqrXgQDZL1LYOpneZkempVMbsHATG9ZukgUcDieDD4ygaIdVfFkMvondC7ybB+M2zw= X-Received: by 2002:aca:af8f:: with SMTP id y137mr13781680oie.55.1609605024857; Sat, 02 Jan 2021 08:30:24 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Alan Somers Date: Sat, 2 Jan 2021 09:30:13 -0700 Message-ID: Subject: Re: cp(1) of large files is causing 100% CPU utilization and poor transfer To: Matthias Apitz , FreeBSD CURRENT X-Rspamd-Queue-Id: 4D7S6n6HHjz4bXt X-Spamd-Bar: / X-Spamd-Result: default: False [-0.99 / 15.00]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; HAS_ATTACHMENT(0.00)[]; MIME_BASE64_TEXT_BOGUS(1.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.09)[-0.090]; MIME_BASE64_TEXT(0.10)[]; RCPT_COUNT_TWO(0.00)[2]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:+]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[209.85.167.172:from]; FREEFALL_USER(0.00)[asomers]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/mixed,multipart/alternative,text/plain,text/x-dsrc]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[freebsd.org]; SPAMHAUS_ZRD(0.00)[209.85.167.172:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[209.85.167.172:from]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.167.172: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" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 02 Jan 2021 16:30:26 -0000 On Sat, Jan 2, 2021 at 9:12 AM Matthias Apitz wrote: > El d=C3=ADa s=C3=A1bado, enero 02, 2021 a las 09:06:24a. m. -0700, Alan S= omers > escribi=C3=B3: > > > > As I said, it can be reproduced using only the local file system. Thi= s > > > was setup recently on a SSD: > > > > > > # dmesg | grep ada0 > > > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > > > ada0: ACS-2 ATA SATA 3.x device > > > ada0: Serial Number F995890846 > > > ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 1024bytes) > > > ada0: Command Queueing enabled > > > ada0: 488386MB (1000215216 512 byte sectors) > > > > > > and by this procedure: > > > > > > # gpart create -s gpt ada0 > > > # gpart add -t freebsd-boot -s 512k -a4k -l ssdboot ada0 > > > # gpart bootcode -b /boot/pmbr -p /boot/gptboot -i1 ada0 > > > # gpart add -t freebsd-ufs -l ssdrootfs -b 1m -s 2g ada0 > > > # gpart add -t freebsd-ufs -l ssdvarfs -a 1m -s 2g ada0 > > > # gpart add -t freebsd-ufs -l ssdusrfs -a 1m ada0 > > > # newfs -U -t /dev/gpt/ssdrootfs > > > # newfs -U -t /dev/gpt/ssdvarfs > > > # newfs -U -t /dev/gpt/ssdusrfs > > > > > > # gpart show -l ada0 > > > =3D> 40 1000215136 ada0 GPT (477G) > > > 40 1024 1 ssdboot (512K) > > > 1064 984 - free - (492K) > > > 2048 4194304 2 ssdrootfs (2.0G) > > > 4196352 4194304 3 ssdvarfs (2.0G) > > > 8390656 16777216 4 ssdswap (8.0G) > > > 25167872 975046656 5 ssdusrfs (465G) > > > 1000214528 648 - free - (324K) > > > > > > # mount -t ufs > > > /dev/gpt/ssdrootfs on / (ufs, local, soft-updates) > > > /dev/gpt/ssdvarfs on /var (ufs, local, soft-updates) > > > /dev/gpt/ssdusrfs on /usr (ufs, local, soft-updates) > > > > > > When I run in the /usr fs the command > > > > > > # cp -p guru-20210102.tar.gz xxx > > > > > > it copies around 168M per minute. > > > > > > Is that copying from /usr to /usr, or from /usr to /var or /? > > # cd /home/backups > # cp -p guru-20210102.tar.gz xxx > > i.e. from /usr to /usr. > > matthias > Ok, let's narrow this down. Could you please run the command with the attached D script ? sudo dtrace -s copy_file_range.d -c "cp -p guru-20210102.tar.gz xxx" From owner-freebsd-current@freebsd.org Sat Jan 2 16:40:14 2021 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 0A71F4D6269 for ; Sat, 2 Jan 2021 16:40:14 +0000 (UTC) (envelope-from herbert@gojira.at) Received: from mail.bsd4all.net (mail.bsd4all.net [94.130.200.20]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail.bsd4all.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D7SL473hqz4ch9 for ; Sat, 2 Jan 2021 16:40:12 +0000 (UTC) (envelope-from herbert@gojira.at) Date: Sat, 02 Jan 2021 17:40:10 +0100 Message-ID: <87o8i7thqt.wl-herbert@gojira.at> From: "Herbert J. Skuhra" To: freebsd-current@freebsd.org Subject: Re: etcupdate, svnlite, documentation etc. following the transition of source to Git In-Reply-To: References: <87lfdctq83.wl-herbert@gojira.at> <87pn2nu3n8.wl-herbert@gojira.at> <1d6c0954-ca13-b3a0-3e82-c79df594e357@gmail.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/28.0 Mule/6.0 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 4D7SL473hqz4ch9 X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.45 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; R_DKIM_ALLOW(-0.20)[gojira.at:s=mail202005]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:94.130.200.20]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[gojira.at]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[94.130.200.20:from:127.0.2.255]; DKIM_TRACE(0.00)[gojira.at:+]; NEURAL_HAM_SHORT(-0.95)[-0.951]; MID_CONTAINS_FROM(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[94.130.200.20:from]; ASN(0.00)[asn:24940, ipnet:94.130.0.0/16, country:DE]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 02 Jan 2021 16:40:14 -0000 On Sat, 02 Jan 2021 17:18:10 +0100, Graham Perrin wrote: > > Sorry for the mis-formatting and lost line breaks in my previous > e-mail. Blame Thunderbird. > > As reference: > > > > /usr/src > > > BSD, third-party, and/or local source files Sorry, what's your point? Why do you think/insist that you have to clone doc/src/ports into /usr/src? -- Herbert From owner-freebsd-current@freebsd.org Sat Jan 2 16:48:28 2021 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 2A1294D69D7 for ; Sat, 2 Jan 2021 16:48:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qv1-xf2b.google.com (mail-qv1-xf2b.google.com [IPv6:2607:f8b0:4864:20::f2b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D7SWc0XZ4z4d6n for ; Sat, 2 Jan 2021 16:48:27 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qv1-xf2b.google.com with SMTP id a4so11010013qvd.12 for ; Sat, 02 Jan 2021 08:48:27 -0800 (PST) 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=JWNdPunWtPBBUP/z/tDsXUu5siVixDFRZvYBAaUb2wg=; b=az2O4eg5i1tKP9gt8jS3MAFN+VdShyIz4lkRbECIazHD9rMm8MdhbrMne7PlCR1DdV TFcKsZRnFERWJcJVyUXTg6YMnm03RJsRis3zDOcnid3UwEd19swSzEN1cGP7oFh59kn6 wQZKFCI9kAK0lG6IZUqsW8xEHSywb600EDT4bu4UuO0iICWhr0+fKJup3non57aJXuAD 6Q79XkQ9OkVtyl0K6wphWRci3P9aFkeIWApfkoag8P0vJEXeFeZBD70MLkEVHP2tWwrk bKwetjRtPYJlBVY825wfni+9eLBN8A9A3ptssVLouLl/7IfJqP044+Ps4JsLe6IkdcRz Lhmw== X-Gm-Message-State: AOAM531eOOShmxNdJq0VuUs7WGkutPA5913YLtL2IOFY5Nqgmj/6SQiV IAhqfgdRvRsBS86Y53110HsWqlaIrP+CyKp7aELlycOtGN9i+Q== X-Google-Smtp-Source: ABdhPJyl44c26BW9/BOTXXUfInxuvdQfwOFFri7YzZi2WbVtKRz8dBodWWD4g0hlGNCLOnyrX96d+3svi1ESXanW7yA= X-Received: by 2002:a05:6214:16cb:: with SMTP id d11mr69144161qvz.62.1609606107150; Sat, 02 Jan 2021 08:48:27 -0800 (PST) MIME-Version: 1.0 References: <87lfdctq83.wl-herbert@gojira.at> In-Reply-To: From: Warner Losh Date: Sat, 2 Jan 2021 09:48:16 -0700 Message-ID: Subject: Re: etcupdate, svnlite, documentation etc. following the transition of source to Git To: Graham Perrin Cc: FreeBSD Current , Lars Engels X-Rspamd-Queue-Id: 4D7SWc0XZ4z4d6n X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 02 Jan 2021 16:48:28 -0000 On Sat, Jan 2, 2021 at 1:31 AM Graham Perrin wrote= : > On 01/01/2021 19:24, Herbert J. Skuhra wrote: > > > On Fri, 01 Jan 2021 20:01:16 +0100, Graham Perrin wrote: > >> At what should have been the end of my first upgrade since the > >> transition to git: > >> > >> cd /usr/src/freebsd-current && make installworld && etcupdate > >> > >> =F0=A0=84=B4=E2=80=93 concluded with a successful installworld, then a= few lines about > >> scanning and skipping certificates, then: > >> > >>> Failed to build new tree. > >> I see the manual page for etcupdate(8) but I'm not sure how to proceed= . > > -s source Specify an alternate source tree to use when buildin= g > > or extracting a =E2=80=9Ccurrent=E2=80=9D tree. Th= e default source > > tree is /usr/src. > > > With the transition to Git > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > > If it's true that /usr/src is _no longer_ a predictable path to the > source files, then is it still appropriate for users' fortunes to > include this FreeBSD tip? > That's 100% not true. The 'src' 'doc' and future 'ports' repos were named that way so you could check them out directly into /usr to get the traditional paths. The git team made no pronouncement about deprecating this, and went to some minor trouble to ensure it would still be easy. I personally haven't used /usr/src in 20 years, but that's just a character defect on my part. Warner From owner-freebsd-current@freebsd.org Sat Jan 2 16:50:57 2021 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 A75174D6EC0 for ; Sat, 2 Jan 2021 16:50:57 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D7SZS6my6z4drZ for ; Sat, 2 Jan 2021 16:50:56 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x736.google.com with SMTP id p14so20038737qke.6 for ; Sat, 02 Jan 2021 08:50:56 -0800 (PST) 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=VwzVnehSkwD+5f38iYTToF6ooy7bSJfXWdzyi03yMOU=; b=GWVomhZyAh6DrIiMfJSw6WF21loQEVKGUYAQ3tb84t+LXAExKPI96b94vD4N+eKITs Wc9WQiTslA2Y54LpqkLWv466OEW3fpq3z3GbxUUNwiqbv8AavH2W63OXjXdMX8MRlB7p 86BuWZvPJPlOJdZvcQR5Iy07IZY5UttQW6DdtEyD4bNdG/xUxhXjjWNCP8UMAIIrn4Vb cz6oqk96lC6ivMX8CE7I1L8ijsIUnpWbdP4J5d8SxhnfNXB/TasqCacxHmfNf+HT+XY9 7+RvnKg/TE82H6vDT2dZ5NWrFDp/jmSY/hQcKYayjIqcRb6TjVfvbJTc8YQPlpfd23C7 FEdw== X-Gm-Message-State: AOAM533OLxk75u18kjmIX28K0sf5QSVIzvhvsXdvDq2eT/KxiiAq1khX T7b/ZUPtx2t768+eomDPpw4i7ZCMYy1JmVIVF5wEzQ== X-Google-Smtp-Source: ABdhPJxUD/Mu1Fm9eVvDj27GJDrCcIiP/V/0JQzZYyqITluTDwmraHIUMmfS7a2ZCu+5FR7U7bEn5rEOgDJiasIlQKU= X-Received: by 2002:ae9:ebd5:: with SMTP id b204mr64414800qkg.195.1609606256373; Sat, 02 Jan 2021 08:50:56 -0800 (PST) MIME-Version: 1.0 References: <87lfdctq83.wl-herbert@gojira.at> <87pn2nu3n8.wl-herbert@gojira.at> <1d6c0954-ca13-b3a0-3e82-c79df594e357@gmail.com> In-Reply-To: <1d6c0954-ca13-b3a0-3e82-c79df594e357@gmail.com> From: Warner Losh Date: Sat, 2 Jan 2021 09:50:45 -0700 Message-ID: Subject: Re: etcupdate, svnlite, documentation etc. following the transition of source to Git To: Graham Perrin Cc: FreeBSD CURRENT X-Rspamd-Queue-Id: 4D7SZS6my6z4drZ X-Spamd-Bar: / X-Spamd-Result: default: False [0.00 / 15.00]; URI_COUNT_ODD(1.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_TO(0.00)[gmail.com]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RBL_DBL_DONT_QUERY_IPS(0.00)[2607:f8b0:4864:20::736:from]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(1.00)[1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; SPAMHAUS_ZRD(0.00)[2607:f8b0:4864:20::736:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::736:from]; R_SPF_NA(0.00)[no SPF record]; 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.34 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 02 Jan 2021 16:50:57 -0000 On Sat, Jan 2, 2021 at 8:43 AM Graham Perrin wrote: > On 02/01/2021 08:47, Herbert J. Skuhra wrote: > > >> < > https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html> > >> still describes use of `svnlite` (not `git` or `got`) and, I guess, > >> might continue to do so for some time. > >> > >> In this context, is `cd /usr/src` still true? > > If you clone the repository to /usr/src instead of e.g. > > /usr/src/freebsd-current. > > Thanks again. > > I imagine that use cases will _eventually_ include trios of directories, > as siblings, for example: > > /usr/src/doc /usr/src/freebsd-stable > > /usr/src/ports > > True: there's the tradition of /usr/ports > > however with all three things moved, or moving, to Git it seems (to me) > sensible to have the source files for ports at > > /usr/src/ports > > For consistency. A cohesive approach. > There's no change. The current preferred way is to clone into /usr all three repos.... /usr/src /usr/doc /usr/ports One is, of course, free to put things where one wants, but that's no different than with svn. Warner From owner-freebsd-current@freebsd.org Sat Jan 2 17:06:08 2021 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 BA6994D7905 for ; Sat, 2 Jan 2021 17:06:08 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-to1can01on0615.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe5d::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 4D7Svz5L4Kz4fkN; Sat, 2 Jan 2021 17:06:07 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DBqoGn2XtrnSti0d+kVUsdYBXD66Iu/SAkHLBt7VCh9OWhIPNRlHNiEgvEYRnfjzj4HBLKbizMVfnadXmK8EV8tOcdzH1Pe9Nps7IHUlLNANPRYTYAaD7XnMEX+hNIUGyhOX8hkwaqDN0iEvetC9p8FE66PrcqWlly9gMGyrAllUva7QqUqp/KiBHZTWj5Hw22wmZEC2UXrXcF+vzFGTy4vhJzZ6kznCcr0P5vKgcYtOvX2Ii7pwYW1buUxkcKaDKi6ulkd85CZqwOHpgB835hFUX+UfzxwVok2htHqLkQ5c6as6YUaHjmrxn+yGfyxzh/VWuQQl6PN1WpwgvvshHA== 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=dkuOsLGiB6U61RafAmDmsw2D/4v3VWoKh5TAT6NaAQw=; b=R/E+OJR8K2AFh6uN4TByPbNXD49pJkMx4jMxQdy5Zh0otm3WVd9UeO7I6v/LuLlL8IlmTYTkcEvL6V/lZxGNgSbxaYBS0kzUAHVAiwFEKT7I/ctTwknyb5BfN7UZ5qOuNIqNx5Tv3f2pFZHqBgqEWdzCJR3OSIEH9otdmKW/jBO/rWRxB6Dhu3AY+vDe4s0+rzBb8Lrg4B1fafBGWtzld8u83r8gCsJ16Q1Im3kH1K4GyDK+6staDudIgshqi0ya3hTMzDCVfRrp8nv8kGgTxKjkx5TziK4z8H9+i18hRtdaJYj/2TcfTOKu2c4aAaxMoaDnN5uj1Kx8AuOMUtIFwA== 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 YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:19::29) by YQBPR0101MB1057.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:d::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3721.19; Sat, 2 Jan 2021 17:06:05 +0000 Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::3d86:c7f9:bc4c:40c0]) by YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::3d86:c7f9:bc4c:40c0%6]) with mapi id 15.20.3721.023; Sat, 2 Jan 2021 17:06:05 +0000 From: Rick Macklem To: Alan Somers , Matthias Apitz , FreeBSD CURRENT CC: Konstantin Belousov , Kirk McKusick Subject: Re: cp(1) of large files is causing 100% CPU utilization and poor transfer Thread-Topic: cp(1) of large files is causing 100% CPU utilization and poor transfer Thread-Index: AQHW4RfbLUWuHSdTW0ScUnflZYfe96oUeW+AgAAFnQCAAAEzAIAAAZMAgAAFFYCAAAcTBA== Date: Sat, 2 Jan 2021 17:06:05 +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: d7d3ae54-460c-4986-d36e-08d8af40b0f1 x-ms-traffictypediagnostic: YQBPR0101MB1057: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:2657; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: XovBxGl9sV4eKVU6Zb02o8h9DVvqwfnqr8Lyyrv4whBF0XyLISCyEZ5SSUPqVhpiOtE1dfRs2v48JfzVpMi7LCE5xCORzD3blvYpe1z4PCGULoPrT1Li21EZrHucnlWMcPODkm4gu2zmtAyPANUMnzR5K284ri7WIkBNljacPTRXiqPbKEvjBpV+6QHLWRy3B49HeqENsHBPh4GshqLsn3h1r/fqYZHFLvaXdsRoN8bvGT6+NEi/0Tcbzz2daLq7eD062yHUihstlSKLULH90Z7ssaBOXuHKhnyW8lMDyu1P27RsfS84BB1jWmQvPBPKDVADPW2Ov43CjiPXa+QAPKMAqNai/Cf36LhCSIioEY/Z5uHJklE18+lFpv0AW2w9joDDdQBhmpvHhfR/4MLgeUKDEQBty4Z2pA3UdUPPJ55TGQ1Og6IcmvRpfMtCegBGVVPjDmhW+xfDjQ7qjXyJAow96PHHQBzGOPGOa31MVur0KbzpCr+ZZoN03I4GLoQWyUQlFCZoP8ElM0gDE42Jkg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(39850400004)(346002)(376002)(136003)(396003)(366004)(786003)(316002)(52536014)(6506007)(66556008)(26005)(66446008)(64756008)(54906003)(5660300002)(76116006)(66946007)(53546011)(7696005)(2906002)(91956017)(8936002)(86362001)(66476007)(110136005)(186003)(33656002)(8676002)(9686003)(55016002)(4326008)(478600001)(966005)(71200400001)(83380400001)(66574015)(21314003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?M2GD/7z/pFU1Y1gZV7DVDOKmC+A7rzLvcDjd5IzkJIs0Xkl1KMjZNyasAo?= =?iso-8859-1?Q?6KUku7haetF1ZhuB8KH7Cyn9sDZG8GLhJTgLIHdjUDkj5rXMJRGA1fx/HL?= =?iso-8859-1?Q?Mvjs0DrjI1/oqU8J2ncilyr6HVeLtTWit2Lklr3J+X9Fu4lxHOtz8cYrlL?= =?iso-8859-1?Q?Up9qRQDpAUeslr8BxKn2IEjdTSWAjN1qVpQqwT6hsHq03fFNa+5IuQEyOE?= =?iso-8859-1?Q?Zl+omIbgZUNUGCVNpV/L27GO0s9HvNbxmQz4uu+ahxEN9GayS87/nbtv5Y?= =?iso-8859-1?Q?w+WSmTdtP4zGxo48APbmfg1fLY7JmdlZC+KCXhHdcTm2exwX5bhH8fOb6y?= =?iso-8859-1?Q?WbBfNTtjS1J3l28L3QVz3ot0wIk48H7RFZYetdRje1tWh1H3BnYnMVq5QJ?= =?iso-8859-1?Q?FJYm9GYQ6YixMg0WJGJghy6MkcWS9B9UwqJzHPyGns7GIAJKnOnxNlJ41Y?= =?iso-8859-1?Q?O9f5P52JTQFEhggMDnFIxUpGoQVk0epQnj5PfnH30SEPrTv/Wf+WpOr7gJ?= =?iso-8859-1?Q?0y4It+I33ROuecTHtMIsvoCieQCIMB9UIuFetsycvWjdI8jTWMFUFuB8mt?= =?iso-8859-1?Q?cxGHeFwmKJqmufWIJFqOeEIcmnMhFM0i8Jq6qhK4xEQqcHwcAg0eewzy+G?= =?iso-8859-1?Q?swRvax2RXJoUfrlSoz581FhluH/41qw7hcHl/ose68Fma6SDKxYiUmT5qK?= =?iso-8859-1?Q?0MgfOxa2Wab3BB6YNTF0CzBQhB8sbF6Utz0FqfDHxl28x07mE0XusNLaPK?= =?iso-8859-1?Q?gmLgYvL27tk32vd1U8oqrdAZ9hZuk7BvLmBA6l++n1CfO0gtMVpIzL7YtO?= =?iso-8859-1?Q?+u5rGYZJApc7MsH3RBvI85l4bleg+R9r3d2yXyedVnHFr4TXr9kosRkoJb?= =?iso-8859-1?Q?se+4vK/wUaf9EyJ6PzbLx6kOZUyNfKCHMsKRgYQDv27cDaIGUNXcUwJxrv?= =?iso-8859-1?Q?eO+hObrYMmgCJj4bnfHnU1ds96kePrWjK3nUWF/jLkVrvUjK/SiYK9axgA?= =?iso-8859-1?Q?rfThWtXZafrEffPO4=3D?= 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: YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: d7d3ae54-460c-4986-d36e-08d8af40b0f1 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jan 2021 17:06:05.3301 (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: kK9TsvSlXqvJZipGkl3h8JhleOd5I5NV5EjPhdfD9ebWGuJIl1RwAjMbFcHUa1kqB2dM4TB1O6MB0xWOYkgoVA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQBPR0101MB1057 X-Rspamd-Queue-Id: 4D7Svz5L4Kz4fkN X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a01:111:f400:fe5d::615:from]; R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector1]; FREEFALL_USER(0.00)[rmacklem]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a01:111:f400::/48]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_SHORT(1.00)[1.000]; RCPT_COUNT_FIVE(0.00)[5]; SPAMHAUS_ZRD(0.00)[2a01:111:f400:fe5d::615:from:127.0.2.255]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[uoguelph.ca:+]; DMARC_POLICY_ALLOW(-0.50)[uoguelph.ca,none]; DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim]; 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.34 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, 02 Jan 2021 17:06:08 -0000 Just fyi, I've reproduced the problem.=0A= All I did was create a 20Gbyte file=0A= on UFS on a slow (4Gbyte or RAM,=0A= slow spinning disk) laptop.=0A= (The UFS file system is just what the installer creates these days.)=0A= =0A= cp still hasn't finished and is definitely=0A= taking a looott longer than dd did.=0A= =0A= I'll start drilling down later to-day.=0A= =0A= I'll admit doing lots of testing of copy_file_range(2)=0A= with large sparse files, but I may have missed testing=0A= a large non-sparse file.=0A= =0A= rick=0A= ps: I've added Kostik and Kirk to the cc.=0A= =0A= =0A= ________________________________________=0A= From: owner-freebsd-current@freebsd.org = on behalf of Alan Somers =0A= Sent: Saturday, January 2, 2021 11:30 AM=0A= To: Matthias Apitz; FreeBSD CURRENT=0A= Subject: Re: cp(1) of large files is causing 100% CPU utilization and poor = transfer=0A= =0A= CAUTION: This email originated from outside of the University of Guelph. Do= not click links or open attachments unless you recognize the sender and kn= ow the content is safe. If in doubt, forward suspicious emails to IThelp@uo= guelph.ca=0A= =0A= =0A= On Sat, Jan 2, 2021 at 9:12 AM Matthias Apitz wrote:=0A= =0A= > El d=EDa s=E1bado, enero 02, 2021 a las 09:06:24a. m. -0700, Alan Somers= =0A= > escribi=F3:=0A= >=0A= > > > As I said, it can be reproduced using only the local file system. Thi= s=0A= > > > was setup recently on a SSD:=0A= > > >=0A= > > > # dmesg | grep ada0=0A= > > > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0=0A= > > > ada0: ACS-2 ATA SATA 3.x device=0A= > > > ada0: Serial Number F995890846=0A= > > > ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 1024bytes)=0A= > > > ada0: Command Queueing enabled=0A= > > > ada0: 488386MB (1000215216 512 byte sectors)=0A= > > >=0A= > > > and by this procedure:=0A= > > >=0A= > > > # gpart create -s gpt ada0=0A= > > > # gpart add -t freebsd-boot -s 512k -a4k -l ssdboot ada0=0A= > > > # gpart bootcode -b /boot/pmbr -p /boot/gptboot -i1 ada0=0A= > > > # gpart add -t freebsd-ufs -l ssdrootfs -b 1m -s 2g ada0=0A= > > > # gpart add -t freebsd-ufs -l ssdvarfs -a 1m -s 2g ada0=0A= > > > # gpart add -t freebsd-ufs -l ssdusrfs -a 1m ada0=0A= > > > # newfs -U -t /dev/gpt/ssdrootfs=0A= > > > # newfs -U -t /dev/gpt/ssdvarfs=0A= > > > # newfs -U -t /dev/gpt/ssdusrfs=0A= > > >=0A= > > > # gpart show -l ada0=0A= > > > =3D> 40 1000215136 ada0 GPT (477G)=0A= > > > 40 1024 1 ssdboot (512K)=0A= > > > 1064 984 - free - (492K)=0A= > > > 2048 4194304 2 ssdrootfs (2.0G)=0A= > > > 4196352 4194304 3 ssdvarfs (2.0G)=0A= > > > 8390656 16777216 4 ssdswap (8.0G)=0A= > > > 25167872 975046656 5 ssdusrfs (465G)=0A= > > > 1000214528 648 - free - (324K)=0A= > > >=0A= > > > # mount -t ufs=0A= > > > /dev/gpt/ssdrootfs on / (ufs, local, soft-updates)=0A= > > > /dev/gpt/ssdvarfs on /var (ufs, local, soft-updates)=0A= > > > /dev/gpt/ssdusrfs on /usr (ufs, local, soft-updates)=0A= > > >=0A= > > > When I run in the /usr fs the command=0A= > > >=0A= > > > # cp -p guru-20210102.tar.gz xxx=0A= > > >=0A= > > > it copies around 168M per minute.=0A= > > >=0A= >=0A= > > Is that copying from /usr to /usr, or from /usr to /var or /?=0A= >=0A= > # cd /home/backups=0A= > # cp -p guru-20210102.tar.gz xxx=0A= >=0A= > i.e. from /usr to /usr.=0A= >=0A= > matthias=0A= >=0A= =0A= Ok, let's narrow this down. Could you please run the command with the=0A= attached D script ?=0A= sudo dtrace -s copy_file_range.d -c "cp -p guru-20210102.tar.gz xxx"=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= From owner-freebsd-current@freebsd.org Sat Jan 2 17:12:39 2021 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 792794D7968 for ; Sat, 2 Jan 2021 17:12:39 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oo1-f41.google.com (mail-oo1-f41.google.com [209.85.161.41]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D7T3W2vdFz4gH5; Sat, 2 Jan 2021 17:12:39 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-oo1-f41.google.com with SMTP id o5so5339641oop.12; Sat, 02 Jan 2021 09:12:39 -0800 (PST) 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=kg4KkpsHB4pjw0aYOg+SmkCLG7KJqhEU4Cje7WQd0s0=; b=EDCgZ2AdTWEH95MJZXyXHY8dbWKa8A4VM9AUoYCGMvKzYLHgYHRqSeOaAkxEUmgdiE YSZ6Lwh241S4ucjM2YK+fmZTbu/zcUj8bODlSTumZXZmHVIMT+O4EPPmzPYC3wY+P0RL bj90JQO/Il0SkVyaTQN3YBTUzVeSa/vJp9eBoDoEqr4CAmz+DYu5XeDrU2LzZQtvlb3T VsUnunEDRtAOiCKJ/RJb/osnLz/0wEoQwV7nHt7fivvkufV4YxOFqGERkVoDOzZSykT5 pSHmeX6yZGaKoy0KaWDNpxqj3gPNLGVhe2zNBN5Oe6ERar1CjtmJ4Aei8HSXSzd6slrP 40Jw== X-Gm-Message-State: AOAM533cttC9bytqhiYBkkVYS3GYFmz38A8a5wB6c6+203dMKMqUIkNr WqTUOP5wkAlKgUuULLMAkqCibSd45ksFAraHP9g= X-Google-Smtp-Source: ABdhPJxA+1N2yB0aEF+SkBX8caG+g7pv7gdZ9UaI383VsSPGL2ljk7JRUSG/IZL61PKCtYFP6m00yRt315s5ApLw8Ps= X-Received: by 2002:a05:6820:34b:: with SMTP id m11mr34815832ooe.74.1609607558176; Sat, 02 Jan 2021 09:12:38 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Alan Somers Date: Sat, 2 Jan 2021 10:12:27 -0700 Message-ID: Subject: Re: cp(1) of large files is causing 100% CPU utilization and poor transfer To: Rick Macklem Cc: Matthias Apitz , FreeBSD CURRENT , Konstantin Belousov , Kirk McKusick X-Rspamd-Queue-Id: 4D7T3W2vdFz4gH5 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 02 Jan 2021 17:12:39 -0000 It seems pretty clear to me, based on my experiments, that FIOSEEKHOLE is O(n) in filesize on UFS (though not on ZFS). And vn_generic_copy_file_range calls VOP_IOCTL(..., FIOSEEKHOLE) once for every block it copies, where blocks can range from 4KB to 1 MB. So I think there are three required actions: 1) Fix vn_generic_copy_file_range to remember the hole locations across different iterations of its loop. 2) Increase the block size that cp uses with copy_file_range. Right now it's 2MB, but it should be much larger. 3) Optionally, improve UFS's FIOSEEKHOLE performance. But it probably won't be necessary if we fix 1 and 2. -Alan On Sat, Jan 2, 2021 at 10:06 AM Rick Macklem wrote: > Just fyi, I've reproduced the problem. > All I did was create a 20Gbyte file > on UFS on a slow (4Gbyte or RAM, > slow spinning disk) laptop. > (The UFS file system is just what the installer creates these days.) > > cp still hasn't finished and is definitely > taking a looott longer than dd did. > > I'll start drilling down later to-day. > > I'll admit doing lots of testing of copy_file_range(2) > with large sparse files, but I may have missed testing > a large non-sparse file. > > rick > ps: I've added Kostik and Kirk to the cc. > > > ________________________________________ > From: owner-freebsd-current@freebsd.org > on behalf of Alan Somers > Sent: Saturday, January 2, 2021 11:30 AM > To: Matthias Apitz; FreeBSD CURRENT > Subject: Re: cp(1) of large files is causing 100% CPU utilization and poo= r > transfer > > CAUTION: This email originated from outside of the University of Guelph. > Do not click links or open attachments unless you recognize the sender an= d > know the content is safe. If in doubt, forward suspicious emails to > IThelp@uoguelph.ca > > > On Sat, Jan 2, 2021 at 9:12 AM Matthias Apitz wrote: > > > El d=C3=ADa s=C3=A1bado, enero 02, 2021 a las 09:06:24a. m. -0700, Alan= Somers > > escribi=C3=B3: > > > > > > As I said, it can be reproduced using only the local file system. > This > > > > was setup recently on a SSD: > > > > > > > > # dmesg | grep ada0 > > > > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > > > > ada0: ACS-2 ATA SATA 3.x device > > > > ada0: Serial Number F995890846 > > > > ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 1024bytes) > > > > ada0: Command Queueing enabled > > > > ada0: 488386MB (1000215216 512 byte sectors) > > > > > > > > and by this procedure: > > > > > > > > # gpart create -s gpt ada0 > > > > # gpart add -t freebsd-boot -s 512k -a4k -l ssdboot ada0 > > > > # gpart bootcode -b /boot/pmbr -p /boot/gptboot -i1 ada0 > > > > # gpart add -t freebsd-ufs -l ssdrootfs -b 1m -s 2g ada0 > > > > # gpart add -t freebsd-ufs -l ssdvarfs -a 1m -s 2g ada0 > > > > # gpart add -t freebsd-ufs -l ssdusrfs -a 1m ada0 > > > > # newfs -U -t /dev/gpt/ssdrootfs > > > > # newfs -U -t /dev/gpt/ssdvarfs > > > > # newfs -U -t /dev/gpt/ssdusrfs > > > > > > > > # gpart show -l ada0 > > > > =3D> 40 1000215136 ada0 GPT (477G) > > > > 40 1024 1 ssdboot (512K) > > > > 1064 984 - free - (492K) > > > > 2048 4194304 2 ssdrootfs (2.0G) > > > > 4196352 4194304 3 ssdvarfs (2.0G) > > > > 8390656 16777216 4 ssdswap (8.0G) > > > > 25167872 975046656 5 ssdusrfs (465G) > > > > 1000214528 648 - free - (324K) > > > > > > > > # mount -t ufs > > > > /dev/gpt/ssdrootfs on / (ufs, local, soft-updates) > > > > /dev/gpt/ssdvarfs on /var (ufs, local, soft-updates) > > > > /dev/gpt/ssdusrfs on /usr (ufs, local, soft-updates) > > > > > > > > When I run in the /usr fs the command > > > > > > > > # cp -p guru-20210102.tar.gz xxx > > > > > > > > it copies around 168M per minute. > > > > > > > > > Is that copying from /usr to /usr, or from /usr to /var or /? > > > > # cd /home/backups > > # cp -p guru-20210102.tar.gz xxx > > > > i.e. from /usr to /usr. > > > > matthias > > > > Ok, let's narrow this down. Could you please run the command with the > attached D script ? > sudo dtrace -s copy_file_range.d -c "cp -p guru-20210102.tar.gz xxx" > _______________________________________________ > 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 Sat Jan 2 18:28:17 2021 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 E8BA24D9E1C for ; Sat, 2 Jan 2021 18:28:17 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D7Vkn2xltz4l6j for ; Sat, 2 Jan 2021 18:28:17 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: by mail-wr1-x436.google.com with SMTP id r3so26907915wrt.2 for ; Sat, 02 Jan 2021 10:28:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=NpK4cT8N3CYD6RbSFRkNKlRNfcajTXM2reRYL/UFbGE=; b=lC76pTEYTEemsC92lU/5Tcd59veFPU9T64UodyufkVgWlODHmvhtruY8m3X6sVX2Fh bOrrBoD2PScKcugeBU1SmT7R3VOZBE4vPxsFBP3mzEChBXswLdSOhcoGlliKfxLeQ7LT v2f19pLT28mMoslsGpn+VaRMu1/d2fTDV76wgJ1tcXVJwV+6pMGzo4PiItRmMDQbtjF7 fImOt6DLFZfb8d4pZAyWAL7+oORfGaXLTEHw67OAe5PUq00Jr4poVH4ZnyMAHZVNdJVN 7JYdiYgP0kTQnm+mCtRAMX+HnhF216TeCDy/MVlCMBjoJAvMrbpJoEEgLrp2VSdtxxmN NKeg== X-Gm-Message-State: AOAM533M5ZY5fluinJUgnWkeAjKTx80kGHte/HL1XdYocpCYlSDohF76 +8z850Lc6T9tUov/uwj6jfqwSKy4+Y8LpQ== X-Google-Smtp-Source: ABdhPJwltcumybP5dsYCi3xT67jnYJQgVGaKnxB2WxgKzUTyXBMQiMvz1WzWnhEJxa1MZq41ivwlDw== X-Received: by 2002:a5d:47cc:: with SMTP id o12mr71956488wrc.236.1609612095646; Sat, 02 Jan 2021 10:28:15 -0800 (PST) Received: from [192.168.1.11] (79-66-147-78.dynamic.dsl.as9105.com. [79.66.147.78]) by smtp.gmail.com with ESMTPSA id h184sm25143956wmh.23.2021.01.02.10.28.14 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 02 Jan 2021 10:28:14 -0800 (PST) Subject: Re: etcupdate, svnlite, documentation etc. following the transition of source to Git To: FreeBSD CURRENT References: <87lfdctq83.wl-herbert@gojira.at> From: Graham Perrin Message-ID: <84d51d51-4802-f26e-2662-b95102075751@gmail.com> Date: Sat, 2 Jan 2021 18:28:14 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-GB X-Rspamd-Queue-Id: 4D7Vkn2xltz4l6j X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.88 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.88)[-0.885]; RECEIVED_SPAMHAUS_PBL(0.00)[79.66.147.78:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a00:1450:4864:20::436:from]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[2a00:1450:4864:20::436:from:127.0.2.255]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::436:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 02 Jan 2021 18:28:18 -0000 On 02/01/2021 16:48, Warner Losh wrote: > > > On Sat, Jan 2, 2021 at 1:31 AM Graham Perrin > wrote: > > On 01/01/2021 19:24, Herbert J. Skuhra wrote: > > > On Fri, 01 Jan 2021 20:01:16 +0100, Graham Perrin wrote: > >> At what should have been the end of my first upgrade since the > >> transition to git: > >> > >> cd /usr/src/freebsd-current && make installworld && etcupdate > >> > >> 𠄴– concluded with a successful installworld, then a few lines > about > >> scanning and skipping certificates, then: > >> > >>> Failed to build new tree. > >> I see the manual page for etcupdate(8) but I'm not sure how to > proceed. > > -s source          Specify an alternate source tree to use when > building > >                     or extracting a “current” tree. The default > source > >                     tree is /usr/src. > > > With the transition to Git > > ========================== > > If it's true that /usr/src is _no longer_ a predictable path to the > source files, then is it still appropriate for users' fortunes to > include this FreeBSD tip? > > > That's 100% not true. The 'src' 'doc' and future 'ports' repos were > named that way so you could check them out directly into /usr to get > the traditional paths. The git team made no pronouncement about > deprecating this, and went to some minor trouble to ensure it would > still be easy. > > I personally haven't used /usr/src in 20 years, but that's just a > character defect on my part. > > Warner Thanks for the clarifications. I'll edit my comments in Reddit. From owner-freebsd-current@freebsd.org Sat Jan 2 18:28:25 2021 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 A19DE4D9D6D for ; Sat, 2 Jan 2021 18:28:25 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4D7Vkx3T0vz4lJ8; Sat, 2 Jan 2021 18:28:25 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from [188.174.60.30] (helo=c720-r368166.unixarea.de) by ms-10.1blu.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kvldX-0004Px-3m; Sat, 02 Jan 2021 19:28:23 +0100 Received: from c720-r368166.fritz.box (localhost [127.0.0.1]) by c720-r368166.unixarea.de (8.16.1/8.14.9) with ESMTPS id 102ISMB0009253 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 2 Jan 2021 19:28:22 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by c720-r368166.fritz.box (8.16.1/8.14.9/Submit) id 102ISL1P009252; Sat, 2 Jan 2021 19:28:21 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: c720-r368166.fritz.box: guru set sender to guru@unixarea.de using -f Date: Sat, 2 Jan 2021 19:28:21 +0100 From: Matthias Apitz To: Rick Macklem Cc: Alan Somers , FreeBSD CURRENT , Konstantin Belousov , Kirk McKusick Subject: Re: cp(1) of large files is causing 100% CPU utilization and poor transfer Message-ID: Reply-To: Matthias Apitz Mail-Followup-To: Rick Macklem , Alan Somers , FreeBSD CURRENT , Konstantin Belousov , Kirk McKusick References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: FreeBSD 13.0-CURRENT r368166 (amd64) X-message-flag: Mails containing HTML will not be read! Please send only plain text. X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 188.174.60.30 X-Rspamd-Queue-Id: 4D7Vkx3T0vz4lJ8 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 02 Jan 2021 18:28:25 -0000 El día sábado, enero 02, 2021 a las 05:06:05p. m. +0000, Rick Macklem escribió: > Just fyi, I've reproduced the problem. > All I did was create a 20Gbyte file > on UFS on a slow (4Gbyte or RAM, > slow spinning disk) laptop. > (The UFS file system is just what the installer creates these days.) > > cp still hasn't finished and is definitely > taking a looott longer than dd did. > > I'll start drilling down later to-day. > > I'll admit doing lots of testing of copy_file_range(2) > with large sparse files, but I may have missed testing > a large non-sparse file. > > rick > ps: I've added Kostik and Kirk to the cc. As the problem seems to be clear now, should I still file a PR? I'm happy to do so. matthias -- Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub ¡Con Cuba no te metas! «» Don't mess with Cuba! «» Leg Dich nicht mit Kuba an! http://www.cubadebate.cu/noticias/2020/12/25/en-video-con-cuba-no-te-metas/ From owner-freebsd-current@freebsd.org Sat Jan 2 18:29:49 2021 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 B3D554D9F72 for ; Sat, 2 Jan 2021 18:29:49 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oi1-f179.google.com (mail-oi1-f179.google.com [209.85.167.179]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D7VmX4F4gz4lbK; Sat, 2 Jan 2021 18:29:48 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-oi1-f179.google.com with SMTP id l207so27380317oib.4; Sat, 02 Jan 2021 10:29:48 -0800 (PST) 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; bh=LmLcjgZwv6Tb4PjhugGOu12x62dk4Zi4l1hIt+HXBYQ=; b=XPQ13cTQ2AthGCW+aOytajOykknChUuZyulUBwGm16UVzIgqcboue7t/k99GxU0Usa cll53NPbOFTzGWOWGkoeUNnYQpbJRjWqtVvmQUKCsLXmtAm7KD84IXFVWV34A2V7xJXL T17BDbYDFwCmCuws817uK8lyq9YzF/ejJdsn1NHKYsMYIzXTLHlPSgUlP1nA6GICpS4+ UvVY5FyRck/cZE5FfU93rwv0h6XlNs2xVhnzEq9v++Kx4yTksgWQmmk/1fmbA3z6ZRjH EKn2GaO52DViOQQLiIk/s4932IzbQBXqz3W5wV7nprdNRmnTGGuq5itdSFZtx0NoMdQ3 WD8A== X-Gm-Message-State: AOAM531oyU2XLvesLzaaSvEq6xfbMqyeRgs16hE0mr4g5RgWBiZ2liCp qu903jeUsqqgBYzgndVoelsQfOeE2bXvQ8IYva0= X-Google-Smtp-Source: ABdhPJxdcW+lYm9+EYFhBextr/lKhFPgUITBqi/xJPDZw/XEglNsJt4NIE1tTqVAWbD568TZgSbrp90TSAtD2btH0CA= X-Received: by 2002:aca:540e:: with SMTP id i14mr13530237oib.57.1609612187618; Sat, 02 Jan 2021 10:29:47 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Alan Somers Date: Sat, 2 Jan 2021 11:29:36 -0700 Message-ID: Subject: Re: cp(1) of large files is causing 100% CPU utilization and poor transfer To: Matthias Apitz , Rick Macklem , Alan Somers , FreeBSD CURRENT , Konstantin Belousov , Kirk McKusick X-Rspamd-Queue-Id: 4D7VmX4F4gz4lbK X-Spamd-Bar: -- X-Spamd-Result: default: False [-2.62 / 15.00]; ARC_NA(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[209.85.167.179:from]; RCVD_COUNT_TWO(0.00)[2]; FREEFALL_USER(0.00)[asomers]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; RCVD_TLS_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_FIVE(0.00)[6]; SPAMHAUS_ZRD(0.00)[209.85.167.179:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.62)[-0.623]; RCVD_IN_DNSWL_NONE(0.00)[209.85.167.179:from]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.167.179:from]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; MAILMAN_DEST(0.00)[freebsd-current] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 02 Jan 2021 18:29:49 -0000 On Sat, Jan 2, 2021 at 11:28 AM Matthias Apitz wrote: > El d=C3=ADa s=C3=A1bado, enero 02, 2021 a las 05:06:05p. m. +0000, Rick M= acklem > escribi=C3=B3: > > > Just fyi, I've reproduced the problem. > > All I did was create a 20Gbyte file > > on UFS on a slow (4Gbyte or RAM, > > slow spinning disk) laptop. > > (The UFS file system is just what the installer creates these days.) > > > > cp still hasn't finished and is definitely > > taking a looott longer than dd did. > > > > I'll start drilling down later to-day. > > > > I'll admit doing lots of testing of copy_file_range(2) > > with large sparse files, but I may have missed testing > > a large non-sparse file. > > > > rick > > ps: I've added Kostik and Kirk to the cc. > > As the problem seems to be clear now, should I still file a PR? > I'm happy to do so. > > matthias > Yes please . That will help ensure that we don't lose track of it. From owner-freebsd-current@freebsd.org Sat Jan 2 18:44:09 2021 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 254864DA9DE for ; Sat, 2 Jan 2021 18:44:09 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D7W543ZnXz4mbs for ; Sat, 2 Jan 2021 18:44:08 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: by mail-wr1-x431.google.com with SMTP id i9so26921722wrc.4 for ; Sat, 02 Jan 2021 10:44:08 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=z4TGGUwnzwvN1UExTDNcbvJ9mTtbP97E6XF8E3iW3Zg=; b=W0aSPTNsOKCJmmVUdnBVcjQV3mo0sFE+SUDVJe1QzSJna0ZXXputuO294nRFKRxHKQ UgQOeDtB4AxlxdeLso/x/1UZUUQAQ2VnHlWTBknyWZQZsHlOWysspYT1kBPrXNNCb9k/ +zHCa9nnEzVPXWbBLgdDAWdCwrye54vZz6BIYKEoXTr1cMs9UM2Ak2algBsQsE2hYDgL KCkBgg6AoYUfH2Gx18czsbaqLSCwkhWlwZ1GjcxDU/9KIU8KK7ZRwLlPcmfzwuWCwedu O4fVENVqV2pawfjMxpwA9T+qG6NuGbDv5Zh8DdsUfBSwSrwKo5rlG1QUvbdMlmum5R+g R6zA== X-Gm-Message-State: AOAM531FL940SuvP7eJXFXrQPdsvc5pCaJUvrL3L2umqLL/ftd/AnZnF DMukaO/tQHdLHMJFhsLAVisIKv+Zrza3Dw== X-Google-Smtp-Source: ABdhPJz+CHNYmjyPf73TmqemYeoNHzlIyHsWD8imndxof1SrCnFyiM2dAyeo8fDQuxKltObAB8u55A== X-Received: by 2002:adf:f891:: with SMTP id u17mr74173080wrp.253.1609613046949; Sat, 02 Jan 2021 10:44:06 -0800 (PST) Received: from [192.168.1.11] (79-66-147-78.dynamic.dsl.as9105.com. [79.66.147.78]) by smtp.gmail.com with ESMTPSA id a25sm23878268wmb.25.2021.01.02.10.44.06 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 02 Jan 2021 10:44:06 -0800 (PST) To: FreeBSD Current From: Graham Perrin Subject: Finding a commit in cgit, given output from uname -a Message-ID: Date: Sat, 2 Jan 2021 18:44:05 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-Rspamd-Queue-Id: 4D7W543ZnXz4mbs X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.89 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.89)[-0.890]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a00:1450:4864:20::431:from]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; RECEIVED_SPAMHAUS_PBL(0.00)[79.66.147.78:received]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[2a00:1450:4864:20::431:from:127.0.2.255]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::431:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 02 Jan 2021 18:44:09 -0000 FreeBSD mowa219-gjp4-8570p 13.0-CURRENT FreeBSD 13.0-CURRENT #0 main-c530-g8b4c3a03f: Fri Jan  1 15:27:15 GMT 2021 root@mowa219-gjp4-8570p:/usr/obj/usr/src/freebsd-current/amd64.amd64/sys/GENERIC-NODEBUG amd64 finds nothing. Am I missing something? From owner-freebsd-current@freebsd.org Sat Jan 2 18:53:16 2021 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 A2FAD4DB040 for ; Sat, 2 Jan 2021 18:53:16 +0000 (UTC) (envelope-from freebsd@grem.de) Received: from mail.evolve.de (mail.evolve.de [213.239.217.29]) (using TLSv1.3 with cipher TLS_CHACHA20_POLY1305_SHA256 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA512 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail.evolve.de", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D7WHb2CxVz4n8f; Sat, 2 Jan 2021 18:53:14 +0000 (UTC) (envelope-from freebsd@grem.de) Received: by mail.evolve.de (OpenSMTPD) with ESMTP id e93c94db; Sat, 2 Jan 2021 18:53:11 +0000 (UTC) Received: by mail.evolve.de (OpenSMTPD) with ESMTPSA id 5f5c3a9a (TLSv1.3:AEAD-CHACHA20-POLY1305-SHA256:256:NO); Sat, 2 Jan 2021 18:53:11 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Subject: Re: Finding a commit in cgit, given output from uname -a From: Michael Gmelin In-Reply-To: Date: Sat, 2 Jan 2021 19:53:10 +0100 Cc: FreeBSD Current Message-Id: <8C3C23B7-18EC-43FA-A0C3-370E79829A9A@grem.de> References: To: Graham Perrin X-Mailer: iPhone Mail (18C66) X-Rspamd-Queue-Id: 4D7WHb2CxVz4n8f X-Spamd-Bar: / X-Spamd-Result: default: False [1.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip4:213.239.217.29/32]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[grem.de:+]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[213.239.217.29:from]; ASN(0.00)[asn:24940, ipnet:213.239.192.0/18, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; FORGED_RECIPIENTS(2.00)[m:grahamperrin@gmail.com,s:grembo@freebsd.org]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[grem.de:s=20180501]; FROM_HAS_DN(0.00)[]; NEURAL_SPAM_SHORT(1.00)[1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[grem.de]; SPAMHAUS_ZRD(0.00)[213.239.217.29:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 02 Jan 2021 18:53:16 -0000 > On 2. Jan 2021, at 19:44, Graham Perrin wrote: >=20 > =EF=BB=BFFreeBSD mowa219-gjp4-8570p 13.0-CURRENT FreeBSD 13.0-CURRENT #0 m= ain-c530-g8b4c3a03f: Fri Jan 1 15:27:15 GMT 2021 root@mowa219-gjp4-8570p:/u= sr/obj/usr/src/freebsd-current/amd64.amd64/sys/GENERIC-NODEBUG amd64 >=20 > finds nothin= g. >=20 > Am I missing something? Remove =E2=80=9Cg=E2=80=9D from the hash. -m >=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 Sat Jan 2 19:21:47 2021 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 849D44DBF0F for ; Sat, 2 Jan 2021 19:21:47 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D7WwW340mz4q1H for ; Sat, 2 Jan 2021 19:21:47 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: by mail-wr1-x42c.google.com with SMTP id d26so26917442wrb.12 for ; Sat, 02 Jan 2021 11:21:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=K78nc+GuhwJD+qT1N6PauS/eVQsLZkQmeGomdTlpXUc=; b=pqhq6wOqc1poQkaRwaQZ1R3Gb2Jrs3eb7Tg8jfULOwmYldzeBuhM5pGKmPlWYNVlzO IbcDj22qLrKubSIG9dIIhHiEyFFgUboMyIWNSWE+AdIvNuznoz5sJoc70ZGtc3x1+6Nx cpViEfbKa3qrygcIB7h4+ftYhme6KxZALUMXgzlk97Pk04MClvgB28Ni2jimQWNK7qZs EM4gAIkOkA10vJwun/QoX/h5Vd3ktSeijYqZEhLK310PAgPQYbHbpujUyjZ216MgH8QC EDH26EUYtyuJqRETg7Nk+gRitGIvQlo3FeyVcNuY9zxvk+a/Ij7+0HGIyRyDKqzoSvvv Y1Jw== X-Gm-Message-State: AOAM532F0o2CcRJrnIUFXw7pp16lscSV9dxmtTT4BgCA7kdpJX8T6Krf sFHaix3+5/xZ9iBWBWe+ZBEdiOw8JhdAYg== X-Google-Smtp-Source: ABdhPJy/T7SYFRqazXKUefeg/qVGIzG0mMRke50wR2i7It5WUFUnZVAYZy8eaSxfSEiDAoqN4E12OA== X-Received: by 2002:a5d:6909:: with SMTP id t9mr71753706wru.327.1609615305612; Sat, 02 Jan 2021 11:21:45 -0800 (PST) Received: from [192.168.1.11] (79-66-147-78.dynamic.dsl.as9105.com. [79.66.147.78]) by smtp.gmail.com with ESMTPSA id n189sm24400119wmf.20.2021.01.02.11.21.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 02 Jan 2021 11:21:44 -0800 (PST) Subject: Re: Finding a commit in cgit, given output from uname -a To: FreeBSD Current Cc: Michael Gmelin References: <8C3C23B7-18EC-43FA-A0C3-370E79829A9A@grem.de> From: Graham Perrin Message-ID: Date: Sat, 2 Jan 2021 19:21:44 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <8C3C23B7-18EC-43FA-A0C3-370E79829A9A@grem.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-Rspamd-Queue-Id: 4D7WwW340mz4q1H X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 02 Jan 2021 19:21:47 -0000 On 02/01/2021 18:53, Michael Gmelin wrote: >> On 2. Jan 2021, at 19:44, Graham Perrin wrote: >> >> FreeBSD mowa219-gjp4-8570p 13.0-CURRENT FreeBSD 13.0-CURRENT #0 main-c530-g8b4c3a03f: Fri Jan 1 15:27:15 GMT 2021 root@mowa219-gjp4-8570p:/usr/obj/usr/src/freebsd-current/amd64.amd64/sys/GENERIC-NODEBUG amd64 >> >> finds nothing. >> >> Am I missing something? > Remove “g” from the hash. > > -m Thank you! I had bookmarked without noticing the accuracy of Ed Maste's ASCII (pointing at the first character _after_ the g) and , which wondered about a typo. Now I see: Probably an obvious question, does the 'g' signify Git? From owner-freebsd-current@freebsd.org Sat Jan 2 19:43:17 2021 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 664704DCD61 for ; Sat, 2 Jan 2021 19:43:17 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4D7XPJ10l3z4rmh for ; Sat, 2 Jan 2021 19:43:15 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (v-critter.freebsd.dk [192.168.55.3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by phk.freebsd.dk (Postfix) with ESMTPS id 107BD8A3C5; Sat, 2 Jan 2021 19:43:14 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.16.1/8.16.1) with ESMTPS id 102JhDrB066836 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 2 Jan 2021 19:43:13 GMT (envelope-from phk@critter.freebsd.dk) Received: (from phk@localhost) by critter.freebsd.dk (8.16.1/8.16.1/Submit) id 102JhDkn066835; Sat, 2 Jan 2021 19:43:13 GMT (envelope-from phk) To: grarpamp cc: freebsd-current@freebsd.org Subject: Re: HEADS UP: FreeBSD src repo transitioning to git this weekend In-reply-to: From: "Poul-Henning Kamp" References: <20201223162417.v7Ce6%steffen@sdaoden.eu> <20201229011939.GU31099@funkthat.com> <20201229210454.Lh4y_%steffen@sdaoden.eu> <20201230004620.GB31099@funkthat.com> <20201231193908.GC31099@funkthat.com> <20210101140857.x3hbci6c4nwi7gl7@mutt-hbsd> <20210102021254.35o3snqb5fcvmbt3@mutt-hbsd> <60082.1609572957@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <66833.1609616593.1@critter.freebsd.dk> Date: Sat, 02 Jan 2021 19:43:13 +0000 Message-ID: <66834.1609616593@critter.freebsd.dk> X-Rspamd-Queue-Id: 4D7XPJ10l3z4rmh X-Spamd-Bar: - X-Spamd-Result: default: False [-1.00 / 15.00]; RCVD_TLS_ALL(0.00)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[130.225.244.222:from]; FREEFALL_USER(0.00)[phk]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.dk]; ARC_NA(0.00)[]; NEURAL_SPAM_SHORT(1.00)[1.000]; SPAMHAUS_ZRD(0.00)[130.225.244.222:from:127.0.2.255]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEMAIL_TO(0.00)[gmail.com]; FORGED_SENDER(0.30)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:1835, ipnet:130.225.0.0/16, country:EU]; FROM_NEQ_ENVFROM(0.00)[phk@phk.freebsd.dk,phk@critter.freebsd.dk]; MAILMAN_DEST(0.00)[freebsd-current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 02 Jan 2021 19:43:17 -0000 -------- grarpamp writes: > > No amount of cryptography can or will protect against that. > > Though it can help attribute that to a source, No. You would end up with the committer saying "it came in as a bug-report, I looked at it, and it looked sensible so I committed it." Unless you are going to *enforce* (how?!) that all committers only commit patches they received under full cryptographic & biometric custody from verified communications partners, it will always end up being unattributable. Even if you were able to pin the blame on a particular committer, that person would simply cease to exist, because it was only a cover identity to begin with. > > As interesting as this thread has been (not!) > > Contrare. > [...] > Defense in depth. ... is a lot harder than most IT-people realize, because most IT-people almost invariably ignore the entire human and political aspect of the problem. See also: "Operation Orchestra" by yours truly. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@freebsd.org Sat Jan 2 20:05:52 2021 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 2AED54DD98E for ; Sat, 2 Jan 2021 20:05:52 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from ms-10.1blu.de (ms-10.1blu.de [178.254.4.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4D7XvN0PyGz4tHj; Sat, 2 Jan 2021 20:05:51 +0000 (UTC) (envelope-from guru@unixarea.de) Received: from [188.174.60.30] (helo=c720-r368166.unixarea.de) by ms-10.1blu.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kvn9q-0001Mu-44; Sat, 02 Jan 2021 21:05:50 +0100 Received: from c720-r368166.fritz.box (localhost [127.0.0.1]) by c720-r368166.unixarea.de (8.16.1/8.14.9) with ESMTPS id 102K5n0N015910 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 2 Jan 2021 21:05:49 +0100 (CET) (envelope-from guru@unixarea.de) Received: (from guru@localhost) by c720-r368166.fritz.box (8.16.1/8.14.9/Submit) id 102K5nEi015909; Sat, 2 Jan 2021 21:05:49 +0100 (CET) (envelope-from guru@unixarea.de) X-Authentication-Warning: c720-r368166.fritz.box: guru set sender to guru@unixarea.de using -f Date: Sat, 2 Jan 2021 21:05:49 +0100 From: Matthias Apitz To: Alan Somers Cc: Rick Macklem , FreeBSD CURRENT , Konstantin Belousov , Kirk McKusick Subject: Re: cp(1) of large files is causing 100% CPU utilization and poor transfer Message-ID: Reply-To: Matthias Apitz Mail-Followup-To: Alan Somers , Rick Macklem , FreeBSD CURRENT , Konstantin Belousov , Kirk McKusick References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Operating-System: FreeBSD 13.0-CURRENT r368166 (amd64) X-message-flag: Mails containing HTML will not be read! Please send only plain text. X-Con-Id: 51246 X-Con-U: 0-guru X-Originating-IP: 188.174.60.30 X-Rspamd-Queue-Id: 4D7XvN0PyGz4tHj X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 02 Jan 2021 20:05:52 -0000 El día sábado, enero 02, 2021 a las 11:29:36a. m. -0700, Alan Somers escribió: > > El día sábado, enero 02, 2021 a las 05:06:05p. m. +0000, Rick Macklem > > escribió: > > > > > Just fyi, I've reproduced the problem. > > > All I did was create a 20Gbyte file > > > on UFS on a slow (4Gbyte or RAM, > > > slow spinning disk) laptop. > > > (The UFS file system is just what the installer creates these days.) > > > > > > cp still hasn't finished and is definitely > > > taking a looott longer than dd did. > > > > > > I'll start drilling down later to-day. > > > > > > I'll admit doing lots of testing of copy_file_range(2) > > > with large sparse files, but I may have missed testing > > > a large non-sparse file. > > > > > > rick > > > ps: I've added Kostik and Kirk to the cc. > > > > As the problem seems to be clear now, should I still file a PR? > > I'm happy to do so. > > > > Yes please . That will help ensure that we don't lose track of it. Here we go: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252358 Thanks matthias -- Matthias Apitz, ✉ guru@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub ¡Con Cuba no te metas! «» Don't mess with Cuba! «» Leg Dich nicht mit Kuba an! http://www.cubadebate.cu/noticias/2020/12/25/en-video-con-cuba-no-te-metas/ From owner-freebsd-current@freebsd.org Sat Jan 2 21:22:39 2021 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 C700A4DFA49 for ; Sat, 2 Jan 2021 21:22:39 +0000 (UTC) (envelope-from melounmichal@gmail.com) 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 4D7Zbz3xpMz3Fh9 for ; Sat, 2 Jan 2021 21:22:39 +0000 (UTC) (envelope-from melounmichal@gmail.com) Received: by mailman.nyi.freebsd.org (Postfix) id 876144DFD15; Sat, 2 Jan 2021 21:22:39 +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 872234DFBED for ; Sat, 2 Jan 2021 21:22:39 +0000 (UTC) (envelope-from melounmichal@gmail.com) Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D7Zbx62ksz3G1T for ; Sat, 2 Jan 2021 21:22:37 +0000 (UTC) (envelope-from melounmichal@gmail.com) Received: by mail-ej1-x630.google.com with SMTP id q22so31570680eja.2 for ; Sat, 02 Jan 2021 13:22:37 -0800 (PST) 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:references :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=M2kzBSw+akGrhm5seXaBLB7+vXw+2iFLM8G+eAJ8WB0=; b=Z7iXmrRbbOdZ2IjowQXzb6sQL6y7lfwPADVJaAl553Yx0krhd0K++0a012uPk4LPcr tSkUc2FHComS+7SrJPyVTluc5TMZxH4AKkIFPp8L7TrYxX3SiJHm2hqntCn1u8YTGZbY 2uLt1dSB0N11QgTk0Za0Th0cMMuzrBiNNSNj+IGnUcERAJCCJpgl2B/mqJ/t7o/yMQ6F 1cuw63HaUNVzsPui8JZANRNGB14bsxOk59BNlBp+0eDrF5M+8E81AD99v4UOk6Qmrs6v ohqKqjEDAZvuMW9yYXzuMchSoPfCWUtfau5gzisYqBTslXxrOExYfA5u6AxurVu+rk9W rdHA== X-Gm-Message-State: AOAM530JUKy/ntGDykQ5JPwYjFDKepJDqhSZJxV6v4pTg+4MEgMrJ1uV OykqW29/liuiR4olP78jYOk4opOzpEkhtQ== X-Google-Smtp-Source: ABdhPJxtEUkEO6lmcaPfGBHRCSjYQCDVMAIbjSH3tOPkHBn7dOcF12I6nccqCgIMuHLX5SsY8CAjsw== X-Received: by 2002:a17:907:1607:: with SMTP id hb7mr59906764ejc.81.1609622555726; Sat, 02 Jan 2021 13:22:35 -0800 (PST) Received: from [88.208.79.100] (halouny.humusoft.cz. [88.208.79.100]) by smtp.gmail.com with ESMTPSA id h12sm22334244ejx.81.2021.01.02.13.22.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 02 Jan 2021 13:22:35 -0800 (PST) Sender: Michal Meloun From: Michal Meloun X-Google-Original-From: Michal Meloun Reply-To: mmel@freebsd.org Subject: Re: Problem compiling git from ports To: Filippo Moretti , Milan Obuch , FreeBSD Current References: <223516195.6185376.1609502236330.ref@mail.yahoo.com> <223516195.6185376.1609502236330@mail.yahoo.com> <32309973.477796.1609513517947@mail.yahoo.com> <680866542.6212528.1609517512906@mail.yahoo.com> <20210101172441.4cf05744@zeta.dino.sk> <1974288110.6258808.1609532377202@mail.yahoo.com> Message-ID: Date: Sat, 2 Jan 2021 22:22:35 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: <1974288110.6258808.1609532377202@mail.yahoo.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4D7Zbx62ksz3G1T X-Spamd-Bar: --- X-Spamd-Result: default: False [-4.00 / 15.00]; HAS_REPLYTO(0.00)[mmel@freebsd.org]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FREEMAIL_TO(0.00)[yahoo.com,dino.sk,freebsd.org]; 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)[]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a00:1450:4864:20::630:from]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; REPLYTO_DOM_NEQ_FROM_DOM(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[current@freebsd.org]; SPAMHAUS_ZRD(0.00)[2a00:1450:4864:20::630:from:127.0.2.255]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::630:from]; RCVD_TLS_ALL(0.00)[]; MAILMAN_DEST(0.00)[current] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 02 Jan 2021 21:22:39 -0000 On 01.01.2021 21:19, Filippo Moretti wrote: > > It worked thank youFilippo > On Friday, January 1, 2021, 5:25:10 PM GMT+1, Milan Obuch wrote: > > On Fri, 1 Jan 2021 16:11:52 +0000 (UTC), Filippo Moretti > wrote: > >> >> I run again portmaster and I have the same error as previously >> reportedFilippo On Friday, January 1, 2021, 4:05:18 PM GMT+1, Filippo >> Moretti wrote: >>   Ufs >> It exits with a different error: >> ===> Installing contributed scripts >> /bin/mkdir -p >> /usr/ports/devel/git/work-default/stage/usr/local/share/git-core/contrib >> cp -f -R /usr/ports/devel/git/work-default/git-2.30.0/contrib/* >> /usr/ports/devel/git/work-default/stage/usr/local/share/git-core/contrib >> ln: >> /usr/ports/devel/git/work-default/stage/usr/local/etc/bash_completion.d//git-completion.bash: >> File exists *** Error code 1 >> >> Stop. >> make[1]: stopped in /usr/ports/devel/git >> *** Error code 1 >> >> Stop. >> make: stopped in /usr/ports/devel/git >> > > I remember seeing this too. I worked around that using options: > > cat /var/db/ports/devel_git/options > # This file is auto-generated by 'make config'. > # Options for git-2.29.2 > _OPTIONS_READ=git-2.29.2 > _FILE_COMPLETE_OPTIONS_LIST=CONTRIB CURL CVS GITWEB GUI HTMLDOCS ICONV NLS P4 PERL SEND_EMAIL SUBTREE SVN PCRE PCRE2 OPTIONS_FILE_SET+=CONTRIB > OPTIONS_FILE_SET+=CURL > OPTIONS_FILE_SET+=CVS > OPTIONS_FILE_UNSET+=GITWEB > OPTIONS_FILE_UNSET+=GUI > OPTIONS_FILE_UNSET+=HTMLDOCS > OPTIONS_FILE_SET+=ICONV > OPTIONS_FILE_UNSET+=NLS > OPTIONS_FILE_SET+=P4 > OPTIONS_FILE_SET+=PERL > OPTIONS_FILE_SET+=SEND_EMAIL > OPTIONS_FILE_UNSET+=SUBTREE > OPTIONS_FILE_UNSET+=SVN > OPTIONS_FILE_SET+=PCRE > OPTIONS_FILE_UNSET+=PCRE2 > > Regards, > Milan This is not related to cache fast lookup, but it is dependency bug of ruby ports. My portmaster -ad session failed with the same issue. I noticed that rubby has been update from 2.6 to 2.7 as part of this sesion. # pkg which /usr/local/bin/asciidoctor /usr/local/bin/asciidoctor was installed by package rubygem-asciidoctor-2.0.10 # ls -l /usr/local/bin/asciidoctor -rwxr-xr-x 1 root wheel 560 Jun 7 2020 /usr/local/bin/asciidoctor # /usr/local/bin/asciidoctor /usr/local/bin/asciidoctor: Command not found # ls -l /usr/local/bin/asciidoctor -rwxr-xr-x 1 root wheel 560 Jun 7 2020 /usr/local/bin/asciidoctor root@tegra210:/usr/ports # more /usr/local/bin/asciidoctor #!/usr/local/bin/ruby26 # # This file was generated by RubyGems. # # The application 'asciidoctor' is installed as part of a gem, and # this file is here to facilitate running it. # ... # ls -l /usr/local/bin/ruby26 ls: /usr/local/bin/ruby26: No such file or directory # portmaster -d rubygem-asciidoctor-2.0.10 ... Installing ruby27-gems-3.0.8... pkg-static: ruby27-gems-3.0.8 conflicts with ruby26-gems-3.0.8 (installs files into the same place). Problematic file: /usr/local/bin/gem ... # pkg info | grep ruby26 ruby26-gems-3.0.8 Package management framework for the Ruby language # pkg delete -f ruby26-gems # portmaster -d rubygem-asciidoctor-2.0.10 # /usr/local/bin/asciidoctor Usage: asciidoctor [OPTION]... FILE... Michal ... From owner-freebsd-current@freebsd.org Sat Jan 2 21:42:14 2021 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 269C84B8E91 for ; Sat, 2 Jan 2021 21:42:14 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-qb1can01on0614.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe5c::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 4D7b2Y0hMKz3H7p; Sat, 2 Jan 2021 21:42:12 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IjxtPLCfaq4+AoC0K0bQMUaRQU3aTQGaajn+wR1POZhgmT4tzG2rGbMabsHp/VIog4irETAoa0zo8naWNwPDkJG5hLhzYrF2x8rn27cQMZCJKRgtZ6pXO9+NOPFlAEt9F05AgPHYBCFBKDhLbTu4+nX/0iYRLLOiOZFLiXpYOtM6TpNFjOqqursmXckusg0hx/2iW2z9SZyqCr93QGKvt4JG+TPZyvBYKPBzl1+DouQt+ur693Jpmi8EavMJqThFj+rJcQemBhiVrj1gcpuJzePryVK+IupNP8PzrrjPLbfizAileWbDpnQPZUUPiUm0gFybsw04huzP+wFgI12Xmg== 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=KqoIFsAYaUYoRDnSMgEFCMz1nLohBOpH+K2vFIZEvBI=; b=f6XcQ69O4FMcqg+jghjGZJlCB/sh6PDq20P9OtLWMnGxhMKztA78EXH/jYMVVNsOwfa+H3gJXxcv/+mCVOC57YyfkZm3U1fXFGb8dUVfT4G6nyAYhl9yOuCsjdFQCgfHgSPqnCtY2HU56423pKy+2E8tNQhJmECjvB9gPKfaeGvRHEQXygTQNqVRCqZ2sbl8OwRuwWz9PW2H/HtJly/9ShKEMukivxsU/iK7jUTHDFCXkiWC/Rbnca11OA+qr5+oCDu9948Mc4W44vzFBM5NGz05aJwdJIKQYEu2Y0YYYDMo8RlakosLlNVPXQrukSUNWEucnrPGvykWj2aAZea01g== 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 YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:19::29) by YQBPR0101MB4179.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c01:9::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3721.23; Sat, 2 Jan 2021 21:42:11 +0000 Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::3d86:c7f9:bc4c:40c0]) by YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::3d86:c7f9:bc4c:40c0%6]) with mapi id 15.20.3721.023; Sat, 2 Jan 2021 21:42:11 +0000 From: Rick Macklem To: Alan Somers , Matthias Apitz CC: FreeBSD CURRENT , Konstantin Belousov , Kirk McKusick Subject: Re: cp(1) of large files is causing 100% CPU utilization and poor transfer Thread-Topic: cp(1) of large files is causing 100% CPU utilization and poor transfer Thread-Index: AQHW4RfbLUWuHSdTW0ScUnflZYfe96oUeW+AgAAFnQCAAAEzAIAAAZMAgAAFFYCAAAcTBIAAGe6AgAAAWgCAABrigIAAGFYC Date: Sat, 2 Jan 2021 21:42:11 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 163ba1de-bef6-4d4b-c9e7-08d8af6742f3 x-ms-traffictypediagnostic: YQBPR0101MB4179: 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: H9bH+Yi/LI8FBgQ/kmU8tlDKszo50yiqJQL3TOQhAor4EBdxIMvn+8RkY7znZmJOBYB+R8LtK1yheijco2ZFDgaIxfKn/LD59Gs41kooelSKrmRkzKQdBHSb5gxKanI3opEW9eQpG5o62lI7PqneV++3CSM+XJailCZipDvTvBJgfGh3Rlive8m01HKq8olwN0LwXfjvfuysvn/RdPv2I/6eUhNVHrn7S0u3I+bXEZdhkbGD5S+tlC0eLxTFcA1vMUqiTuDfa+DKN3moAw7+YGrv606lFIs0ns7ZQAJVFsXt2jyUQjUW5pI+GxV3F4zMBxB12ljDpP2AzWEz4/yFlKvJ8cY0GEGjV9wwSN2HzBkx89K3uHCygMSeFIpKeUvV4zYFXq2Qa42kid66Lv/PAd4b1ilLgWsS8UUgLcMIP1rlm6c5mLshSiOZiy+JWSWSqbSVZzgcIbBdBz76mBJ+9Wd+QNShAo7XzgRjj0UGH/qnJ1ZWfhvn/+9aHSAgxoNAtIXMBr4ybrn2G4IcGh2nrw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(366004)(376002)(39850400004)(396003)(346002)(136003)(5660300002)(33656002)(186003)(6506007)(966005)(478600001)(7696005)(71200400001)(26005)(8936002)(66574015)(53546011)(83080400002)(9686003)(55016002)(2906002)(83380400001)(8676002)(316002)(52536014)(99936003)(54906003)(4326008)(66556008)(64756008)(66476007)(66446008)(86362001)(66616009)(91956017)(110136005)(786003)(76116006)(66946007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?RUFWWGdka01DUUtZVFFqOHVnL05ZZXBrTktZNVlHNHNqVzVCampRaHh4Zndi?= =?utf-8?B?L2drak85M1VBbXRrTXBQRWl4Zy84ay9KY00yem5RZkZVSEQzYlpTSFNtTzhD?= =?utf-8?B?dFdUSHNuQ1grd1B4RjVUdGY4U2dDRUttVEpDMExzMkZtdDR5QitGWDZueGxB?= =?utf-8?B?WTMzKzEwbnNjRXovSnI0aW4rVElveGZyY2JYNTZLb1MwVUIwQnJWai9wVjRp?= =?utf-8?B?bHY5Y0Y0QWI2V1hjSnUyNHp1OUxiWlhWQllnNW1qUGVtS0t5YVlvU2E1K08z?= =?utf-8?B?cWozUWkwTndRSHc1LytZN2NsSlFwMk9xRHZOQ2VoMUJzUXd5b3U2MDFUaWQ2?= =?utf-8?B?MGwrL0dqT1NMMVJxcmE1UG40V0JVbTRBdmJEVW9PVWIveG9HTERhMDVGdHFS?= =?utf-8?B?UlpnYnN0d2hqMDB5bVhLUkRtSkpaZnQvZ3hOLzJoYUpRRUNTVXQ4SVoyNUdQ?= =?utf-8?B?dXV4VlQwZzBpY29HUEY3bGxlRTRTMW96WjA4T2NXcmk2bm5maVJxVWpxVW5B?= =?utf-8?B?dW82ejd0elBCc3hxa1E1WXVoMWlzT1haamgvVWZCdEZuRUszVXFxUnE0MlNL?= =?utf-8?B?aVV2TjBLL25DZHZ1bkJ3Q1B4cWZRNGYxQitxLzlQZWxxSXJjdDA2ZjQxdXNm?= =?utf-8?B?YlJaSTZwV2MwcUVhN05kSU1Wazdobzl6WVRRb0NnVWhvT2pVMG81NHpoNTUx?= =?utf-8?B?dm5NdzhqQlEvenVCMU1QWmJ3N3ZpMytNTFJ1VTNFeU9id1M4VERtMjdXc21D?= =?utf-8?B?eldicXhPRElWMUtZSjRZZDkrRWZMSUl4Y2I3NEF4QW9VTjZ4cUxON2dONzNQ?= =?utf-8?B?dEsrTzlTNUcyUEdlS1ZjSU4wcXhucUc3MXFaM3pNRWlHU2Q0bWlIcVRudy9T?= =?utf-8?B?U1FrcTdSSmNwaldYWmlBTTM0TE5rSUV0M05DNUJCSDNwTnlibEpJVzY4YUc2?= =?utf-8?B?YjRsL3MxZDZIdytZUnBDQ0UyVzVNMHppdEgwQlhqYlYveVo4ditOWENGdThY?= =?utf-8?B?eHFwTmY0ZW1OZE8yL0JEVDB0MDRxbjkwWVNwbFZwM2FzYjFYcEVZbkx0a0Y3?= =?utf-8?B?cEpTTXBCVkZGa3huMVhLZlV1bmlTUEZtaTZrekFIZ0NGanpScFlyYU9YVWdI?= =?utf-8?B?TEs4bGY2NS81TFFXSURyM2krUEJFeVloQlY2bElWb3V2NHF1cWFhN3RVQm5u?= =?utf-8?B?d01yM0NHdndnSTVqSkpVQ0c4Vmpvb0Q2azN0clptc3poSS9zUm92bElpUWh5?= =?utf-8?B?LzRlcHdnaW1GQXg3anlKREcrdFJZd3ZsN3Y1N1NQN0VsMlhXYnRGenU4eklD?= =?utf-8?Q?HftuqthK8xwwg=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/mixed; boundary="_002_YQXPR0101MB096840F865CBD05DFC931A8BDDD40YQXPR0101MB0968_" MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 163ba1de-bef6-4d4b-c9e7-08d8af6742f3 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jan 2021 21:42:11.1541 (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: XOUYIcD417p7R4R3UFipLWfxxWAuLt8mXNd8JW6V34GbFyjJcNz9bYFp/6KKtDsozLZdX2YwpyZHBgv26AbmSw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQBPR0101MB4179 X-Rspamd-Queue-Id: 4D7b2Y0hMKz3H7p X-Spamd-Bar: ----- X-Spamd-Result: default: False [-5.90 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a01:111:f400:fe5c::614:from]; R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector1]; FREEFALL_USER(0.00)[rmacklem]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a01:111:f400::/48]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; HAS_ATTACHMENT(0.00)[]; RCPT_COUNT_FIVE(0.00)[5]; SPAMHAUS_ZRD(0.00)[2a01:111:f400:fe5c::614:from:127.0.2.255]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[uoguelph.ca:+]; MIME_BASE64_TEXT(0.10)[]; DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[uoguelph.ca,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; 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.34 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, 02 Jan 2021 21:42:14 -0000 --_002_YQXPR0101MB096840F865CBD05DFC931A8BDDD40YQXPR0101MB0968_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIGF0dGFjaGVkIHNtYWxsIHBhdGNoIHNlZW1zIHRvIGZpeCB0aGUgcHJvYmxlbS4NCk15IGh1 bmNoIGlzIHRoYXQsIGZvciBhIGxhcmdlIG5vbi1zcGFyc2UgZmlsZSwgU0VFS19EQVRBDQpTRUVL X0hPTEUgdGFrZXMgYSBmYWlybHkgbG9uZyB0aW1lLg0KVGhlc2UgYXJlIGRvbmUgZm9yIGVhY2gg Y29weV9maWxlX3JhbmdlKDIpIHN5c2NhbGwuDQoNCmNwIHdhcyBkb2luZyBsb3RzIG9mIHRoZW0g YmVjYXVzZSBvZiB0aGUgc21hbGwgbGVuIGFyZ3VtZW50Lg0KQnVtcGluZyB0aGUgbGVuIHVwIHRv IFNTSVpFX01BWCByZXN1bHRzIGluIGZhciBmZXdlciBzeWNhbGxzDQphbmQsIHRoZXJlZm9yZSwg U0VFS19EQVRBcyBhbmQgU0VFS19IT0xFcy4NCg0KV2l0aG91dCB0aGUgcGF0Y2gsIGNwIHRvb2sg NiB0aW1lcyBhcyBsb25nIGFzIGRkLg0KV2l0aCB0aGUgcGF0Y2gsIGNwIHRha2VzIGxlc3MgdGlt ZSB0aGFuIGRkLg0KDQpJJ2xsIHB1dCB0aGUgcGF0Y2ggb24gdGhlIGJ1ZyByZXBvcnQuIE1hdHRo aWFzLCBjYW4geW91IHRlc3QNCnRoZSBwYXRjaD8NCg0KVGhhbmtzIGZvciByZXBvcnRpbmcgdGhp cywgcmljaw0KcHM6IEFsbCBteSB0ZXN0IHByb2dyYW1zIHVzZSBTU0laRV9NQVggdW5sZXNzIHRo ZXkgd2VyZQ0KICAgICBub3Qgc3VwcG9zZWQgdG8gY29weSB0byBlb2YsIHdoaWNoIGV4cGxhaW5z IHdoeSBJDQogICAgIG1pc3NlZCB0aGlzLiBNeSBiYWQsIGZvciB0aGUgdGVzdGluZy47LSkNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJvbTogb3duZXItZnJl ZWJzZC1jdXJyZW50QGZyZWVic2Qub3JnIDxvd25lci1mcmVlYnNkLWN1cnJlbnRAZnJlZWJzZC5v cmc+IG9uIGJlaGFsZiBvZiBNYXR0aGlhcyBBcGl0eiA8Z3VydUB1bml4YXJlYS5kZT4NClNlbnQ6 IFNhdHVyZGF5LCBKYW51YXJ5IDIsIDIwMjEgMzowNSBQTQ0KVG86IEFsYW4gU29tZXJzDQpDYzog UmljayBNYWNrbGVtOyBGcmVlQlNEIENVUlJFTlQ7IEtvbnN0YW50aW4gQmVsb3Vzb3Y7IEtpcmsg TWNLdXNpY2sNClN1YmplY3Q6IFJlOiBjcCgxKSBvZiBsYXJnZSBmaWxlcyBpcyBjYXVzaW5nIDEw MCUgQ1BVIHV0aWxpemF0aW9uIGFuZCBwb29yIHRyYW5zZmVyDQoNCkNBVVRJT046IFRoaXMgZW1h aWwgb3JpZ2luYXRlZCBmcm9tIG91dHNpZGUgb2YgdGhlIFVuaXZlcnNpdHkgb2YgR3VlbHBoLiBE byBub3QgY2xpY2sgbGlua3Mgb3Igb3BlbiBhdHRhY2htZW50cyB1bmxlc3MgeW91IHJlY29nbml6 ZSB0aGUgc2VuZGVyIGFuZCBrbm93IHRoZSBjb250ZW50IGlzIHNhZmUuIElmIGluIGRvdWJ0LCBm b3J3YXJkIHN1c3BpY2lvdXMgZW1haWxzIHRvIElUaGVscEB1b2d1ZWxwaC5jYQ0KDQoNCkVsIGTD rWEgc8OhYmFkbywgZW5lcm8gMDIsIDIwMjEgYSBsYXMgMTE6Mjk6MzZhLiBtLiAtMDcwMCwgQWxh biBTb21lcnMgZXNjcmliacOzOg0KDQo+ID4gRWwgZMOtYSBzw6FiYWRvLCBlbmVybyAwMiwgMjAy MSBhIGxhcyAwNTowNjowNXAuIG0uICswMDAwLCBSaWNrIE1hY2tsZW0NCj4gPiBlc2NyaWJpw7M6 DQo+ID4NCj4gPiA+IEp1c3QgZnlpLCBJJ3ZlIHJlcHJvZHVjZWQgdGhlIHByb2JsZW0uDQo+ID4g PiBBbGwgSSBkaWQgd2FzIGNyZWF0ZSBhIDIwR2J5dGUgZmlsZQ0KPiA+ID4gb24gVUZTIG9uIGEg c2xvdyAoNEdieXRlIG9yIFJBTSwNCj4gPiA+IHNsb3cgc3Bpbm5pbmcgZGlzaykgbGFwdG9wLg0K PiA+ID4gKFRoZSBVRlMgZmlsZSBzeXN0ZW0gaXMganVzdCB3aGF0IHRoZSBpbnN0YWxsZXIgY3Jl YXRlcyB0aGVzZSBkYXlzLikNCj4gPiA+DQo+ID4gPiBjcCBzdGlsbCBoYXNuJ3QgZmluaXNoZWQg YW5kIGlzIGRlZmluaXRlbHkNCj4gPiA+IHRha2luZyBhIGxvb290dCBsb25nZXIgdGhhbiBkZCBk aWQuDQo+ID4gPg0KPiA+ID4gSSdsbCBzdGFydCBkcmlsbGluZyBkb3duIGxhdGVyIHRvLWRheS4N Cj4gPiA+DQo+ID4gPiBJJ2xsIGFkbWl0IGRvaW5nIGxvdHMgb2YgdGVzdGluZyBvZiBjb3B5X2Zp bGVfcmFuZ2UoMikNCj4gPiA+IHdpdGggbGFyZ2Ugc3BhcnNlIGZpbGVzLCBidXQgSSBtYXkgaGF2 ZSBtaXNzZWQgdGVzdGluZw0KPiA+ID4gYSBsYXJnZSBub24tc3BhcnNlIGZpbGUuDQo+ID4gPg0K PiA+ID4gcmljaw0KPiA+ID4gcHM6IEkndmUgYWRkZWQgS29zdGlrIGFuZCBLaXJrIHRvIHRoZSBj Yy4NCj4gPg0KPiA+IEFzIHRoZSBwcm9ibGVtIHNlZW1zIHRvIGJlIGNsZWFyIG5vdywgc2hvdWxk IEkgc3RpbGwgZmlsZSBhIFBSPw0KPiA+IEknbSBoYXBweSB0byBkbyBzby4NCj4gPg0KPg0KPiBZ ZXMgcGxlYXNlIC4gIFRoYXQgd2lsbCBoZWxwIGVuc3VyZSB0aGF0IHdlIGRvbid0IGxvc2UgdHJh Y2sgb2YgaXQuDQoNCkhlcmUgd2UgZ286IGh0dHBzOi8vYnVncy5mcmVlYnNkLm9yZy9idWd6aWxs YS9zaG93X2J1Zy5jZ2k/aWQ9MjUyMzU4DQoNClRoYW5rcw0KDQogICAgICAgIG1hdHRoaWFzDQoN Ci0tDQpNYXR0aGlhcyBBcGl0eiwg4pyJIGd1cnVAdW5peGFyZWEuZGUsIGh0dHA6Ly93d3cudW5p eGFyZWEuZGUvICs0OS0xNzYtMzg5MDIwNDUNClB1YmxpYyBHbnVQRyBrZXk6IGh0dHA6Ly93d3cu dW5peGFyZWEuZGUva2V5LnB1Yg0KwqFDb24gQ3ViYSBubyB0ZSBtZXRhcyEgIMKrwrsgIERvbid0 IG1lc3Mgd2l0aCBDdWJhISAgwqvCuyAgTGVnIERpY2ggbmljaHQgbWl0IEt1YmEgYW4hDQpodHRw Oi8vd3d3LmN1YmFkZWJhdGUuY3Uvbm90aWNpYXMvMjAyMC8xMi8yNS9lbi12aWRlby1jb24tY3Vi YS1uby10ZS1tZXRhcy8NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpmcmVlYnNkLWN1cnJlbnRAZnJlZWJzZC5vcmcgbWFpbGluZyBsaXN0DQpodHRwczov L2xpc3RzLmZyZWVic2Qub3JnL21haWxtYW4vbGlzdGluZm8vZnJlZWJzZC1jdXJyZW50DQpUbyB1 bnN1YnNjcmliZSwgc2VuZCBhbnkgbWFpbCB0byAiZnJlZWJzZC1jdXJyZW50LXVuc3Vic2NyaWJl QGZyZWVic2Qub3JnIg0K --_002_YQXPR0101MB096840F865CBD05DFC931A8BDDD40YQXPR0101MB0968_ Content-Type: application/octet-stream; name="cp.patch" Content-Description: cp.patch Content-Disposition: attachment; filename="cp.patch"; size=685; creation-date="Sat, 02 Jan 2021 21:42:06 GMT"; modification-date="Sat, 02 Jan 2021 21:42:06 GMT" Content-Transfer-Encoding: base64 LS0tIGJpbi9jcC91dGlscy5jLnNhdgkyMDIwLTA5LTI2IDE4OjE1OjQwLjA3MjYzMTAwMCAtMDcw MAorKysgYmluL2NwL3V0aWxzLmMJMjAyMC0wOS0yNyAxNzozOTo1Ny40MDQzMjUwMDAgLTA3MDAK QEAgLTc3LDcgKzc3LDcgQEAgX19GQlNESUQoIiRGcmVlQlNEOiBoZWFkL2Jpbi9jcC91dGlscy5j IDM2NTY0MyAyMDIwLTA5CiBzdGF0aWMgaW50CiBjb3B5X2ZhbGxiYWNrKGludCBmcm9tX2ZkLCBp bnQgdG9fZmQsIGNoYXIgKmJ1Ziwgc2l6ZV90IGJ1ZnNpemUpCiB7Ci0JaW50IHJjb3VudDsKKwlz c2l6ZV90IHJjb3VudDsKIAlzc2l6ZV90IHdyZXNpZCwgd2NvdW50ID0gMDsKIAljaGFyICpidWZw OwogCkBAIC0yMzYsNyArMjM2LDcgQEAgY29weV9maWxlKGNvbnN0IEZUU0VOVCAqZW50cCwgaW50 IGRuZSkKIAkJCWRvIHsKIAkJCQlpZiAodXNlX2NvcHlfZmlsZV9yYW5nZSkgewogCQkJCQlyY291 bnQgPSBjb3B5X2ZpbGVfcmFuZ2UoZnJvbV9mZCwgTlVMTCwKLQkJCSAgICAJCSAgICB0b19mZCwg TlVMTCwgYnVmc2l6ZSwgMCk7CisJCQkgICAgCQkgICAgdG9fZmQsIE5VTEwsIFNTSVpFX01BWCwg MCk7CiAJCQkJCWlmIChyY291bnQgPCAwICYmIGVycm5vID09IEVJTlZBTCkgewogCQkJCQkJLyog UHJvYiBhIG5vbi1zZWVrYWJsZSBGRCAqLwogCQkJCQkJdXNlX2NvcHlfZmlsZV9yYW5nZSA9IDA7 Cg== --_002_YQXPR0101MB096840F865CBD05DFC931A8BDDD40YQXPR0101MB0968_-- From owner-freebsd-current@freebsd.org Sat Jan 2 22:09:08 2021 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 BBD3F4BA49C for ; Sat, 2 Jan 2021 22:09:08 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oi1-f175.google.com (mail-oi1-f175.google.com [209.85.167.175]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D7bdc4nlzz3Jy5; Sat, 2 Jan 2021 22:09:08 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-oi1-f175.google.com with SMTP id s75so27783679oih.1; Sat, 02 Jan 2021 14:09:08 -0800 (PST) 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=VR04DHZ9FVpfgvAEaOPWvboWixPijn1Z3KN4JFCCTCw=; b=jg6nTa3h9A9/YALNVWGtr4Z4vDZ4GOfFE9hoInm/0uYcE99bf8Hr9wJ4F5HioaWpbv e6ECZFduKsWPJUR9rU4kS0iKiSF5Y1r+O68AVoWlri10dflUBYof9265g5gzhit86xMD 5OvHkE7rrY9/r6GocTqAKPicZu+kiyQ9cs4nKY8yif5tMVc8Vk0mgw+NwoaeTOvxuL1r +Ww71gDdtOoqde+ivi+tVLtf1ZuV/9Lalu6f1MrIoiYgvUXb1fSzUa9+Xwx4GJQyctFM 0H8ZR1H5rmK1DOXD/NZRadLojwEEHhmtyVQeBxxhUzeJYFRCNmQYEX58n8E/tMd2g810 5U9Q== X-Gm-Message-State: AOAM5312mKRkzueWRnYp34+aHOZEfkMGC8dDFx15K1DnqncUrnc8xzdV QlK0vbD43ImQ+MUe6p8vHNOwsFhqb7txmajHxlw= X-Google-Smtp-Source: ABdhPJwrjbdg17aU0Ck+BcuIuusI7r+6XU2yns9w0+VMH2CH+SZLGNIkYa0QcgfA2p1NZdI93Pf17CV5smut+Q7Q8Kw= X-Received: by 2002:aca:dd09:: with SMTP id u9mr14132494oig.73.1609625347436; Sat, 02 Jan 2021 14:09:07 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Alan Somers Date: Sat, 2 Jan 2021 15:08:56 -0700 Message-ID: Subject: Re: cp(1) of large files is causing 100% CPU utilization and poor transfer To: Rick Macklem Cc: Matthias Apitz , FreeBSD CURRENT , Konstantin Belousov , Kirk McKusick X-Rspamd-Queue-Id: 4D7bdc4nlzz3Jy5 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.34 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.34 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, 02 Jan 2021 22:09:08 -0000 LGTM! This patch also fixes another problem: the previous version of cp, when copying a large sparse file on UFS, would create some UFS indirect blocks (because it would keep truncating the file to larger sizes). The output file would still be sparse, but it would take up more space than the original. IIRC about 0.2% of the empty space would get used by UFS indirect blocks. But your patch fixes it. What I said earlier about needing to modify vn_generic_copy_file_range wasn't quite correct. I confused len with xfer when I was reading the code. The change I proposed to vn_generic_copy_file_range would only make a difference if the process receives many interrupts. And here's some background for other people reading the thread: the reason that the initial copy_file_range implementation in cp only used a 2 MB block size is because vn_generic_copy_file_range wasn't always interruptible, and we didn't want cp to block for minutes or even hours during a long transfer. Subsequently rmacklem made vn_generic_copy_file_range interruptible, but we never raised the block size in cp. -Alan On Sat, Jan 2, 2021 at 2:42 PM Rick Macklem wrote: > The attached small patch seems to fix the problem. > My hunch is that, for a large non-sparse file, SEEK_DATA > SEEK_HOLE takes a fairly long time. > These are done for each copy_file_range(2) syscall. > > cp was doing lots of them because of the small len argument. > Bumping the len up to SSIZE_MAX results in far fewer sycalls > and, therefore, SEEK_DATAs and SEEK_HOLEs. > > Without the patch, cp took 6 times as long as dd. > With the patch, cp takes less time than dd. > > I'll put the patch on the bug report. Matthias, can you test > the patch? > > Thanks for reporting this, rick > ps: All my test programs use SSIZE_MAX unless they were > not supposed to copy to eof, which explains why I > missed this. My bad, for the testing.;-) > > ________________________________________ > From: owner-freebsd-current@freebsd.org > on behalf of Matthias Apitz > Sent: Saturday, January 2, 2021 3:05 PM > To: Alan Somers > Cc: Rick Macklem; FreeBSD CURRENT; Konstantin Belousov; Kirk McKusick > Subject: Re: cp(1) of large files is causing 100% CPU utilization and poo= r > transfer > > CAUTION: This email originated from outside of the University of Guelph. > Do not click links or open attachments unless you recognize the sender an= d > know the content is safe. If in doubt, forward suspicious emails to > IThelp@uoguelph.ca > > > El d=C3=ADa s=C3=A1bado, enero 02, 2021 a las 11:29:36a. m. -0700, Alan S= omers > escribi=C3=B3: > > > > El d=C3=ADa s=C3=A1bado, enero 02, 2021 a las 05:06:05p. m. +0000, Ri= ck Macklem > > > escribi=C3=B3: > > > > > > > Just fyi, I've reproduced the problem. > > > > All I did was create a 20Gbyte file > > > > on UFS on a slow (4Gbyte or RAM, > > > > slow spinning disk) laptop. > > > > (The UFS file system is just what the installer creates these days.= ) > > > > > > > > cp still hasn't finished and is definitely > > > > taking a looott longer than dd did. > > > > > > > > I'll start drilling down later to-day. > > > > > > > > I'll admit doing lots of testing of copy_file_range(2) > > > > with large sparse files, but I may have missed testing > > > > a large non-sparse file. > > > > > > > > rick > > > > ps: I've added Kostik and Kirk to the cc. > > > > > > As the problem seems to be clear now, should I still file a PR? > > > I'm happy to do so. > > > > > > > Yes please . That will help ensure that we don't lose track of it. > > Here we go: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D252358 > > Thanks > > matthias > > -- > Matthias Apitz, =E2=9C=89 guru@unixarea.de, http://www.unixarea.de/ > +49-176-38902045 > Public GnuPG key: http://www.unixarea.de/key.pub > =C2=A1Con Cuba no te metas! =C2=AB=C2=BB Don't mess with Cuba! =C2=AB= =C2=BB Leg Dich nicht mit > Kuba an! > http://www.cubadebate.cu/noticias/2020/12/25/en-video-con-cuba-no-te-meta= s/ > _______________________________________________ > 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 Sat Jan 2 22:12:55 2021 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 300344BA631 for ; Sat, 2 Jan 2021 22:12:55 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D7bjy1XYsz3Jrl for ; Sat, 2 Jan 2021 22:12:54 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: by mail-ej1-x62b.google.com with SMTP id ce23so31622782ejb.8 for ; Sat, 02 Jan 2021 14:12:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=MJJ9Iabn/Ezbs00bFCHPam3fKdI35szLfWBBFrosdd0=; b=hzRn42EQY5Cr6GuGKQQLJgxBCgrCXpDjDYznjJpEdjgCJKFhyqsPfRJdGjGyu8aE9i 1eQM/B4eNLE7WPLGw61Z3IvuzS7udIbAmonleEWyVbR/xDELffaQk9zPT3soSr+63KlF rzlQqLtsdwW8wYiZuMoJGnZU5dZhvd909L+SN+vXY0Oms5y5OLaw7mrrBnwD0I2sqYo/ /ssoQETY9oiOWQhxT21Su+kKp1jv6i1H9Ro9C2QH4grfssd5yxIuZcO7LfXVg3FpEo4W qYCmFdHKFGDILXiTxnMZN60lTdBBsGidGhqzTOKgyS/PxJzwdK6w7zfK1bnwr4wh2r0U rHlw== X-Gm-Message-State: AOAM530ol6u6QYTv/tm3BuiUE+EdfMJagMdbRiRgpvFv6+h09pcSnsiZ clMW61eKrZ/hT9sHQ4uK001V6KtilXAYt5qgwmQC6Gdp9QkMRg== X-Google-Smtp-Source: ABdhPJwnlqHRNN1AACiJewNQcdRcUnZnvot37f9W1knNK9e+17lvCnVvAkjVQ+czxkIEgQUsHQo6tNOnagzpdIrZ+o8= X-Received: by 2002:a17:906:b082:: with SMTP id x2mr57760570ejy.100.1609625571384; Sat, 02 Jan 2021 14:12:51 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a54:3d8d:0:0:0:0:0 with HTTP; Sat, 2 Jan 2021 14:12:50 -0800 (PST) In-Reply-To: <66834.1609616593@critter.freebsd.dk> References: <20201223162417.v7Ce6%steffen@sdaoden.eu> <20201229011939.GU31099@funkthat.com> <20201229210454.Lh4y_%steffen@sdaoden.eu> <20201230004620.GB31099@funkthat.com> <20201231193908.GC31099@funkthat.com> <20210101140857.x3hbci6c4nwi7gl7@mutt-hbsd> <20210102021254.35o3snqb5fcvmbt3@mutt-hbsd> <60082.1609572957@critter.freebsd.dk> <66834.1609616593@critter.freebsd.dk> From: grarpamp Date: Sat, 2 Jan 2021 17:12:50 -0500 Message-ID: Subject: Re: HEADS UP: FreeBSD src repo transitioning to git this weekend To: freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4D7bjy1XYsz3Jrl X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.98 / 15.00]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; TO_DN_NONE(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.98)[-0.976]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RBL_DBL_DONT_QUERY_IPS(0.00)[2a00:1450:4864:20::62b:from]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; SPAMHAUS_ZRD(0.00)[2a00:1450:4864:20::62b:from:127.0.2.255]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::62b: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.34 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, 02 Jan 2021 22:12:55 -0000 >> Though it can help attribute that to a source, Meaning to source 'account', vs say weak old CVSROOT that any could text edit on 200 account box, claim bitrot, etc. Whether inspiration came from the pet dog's bug report is moot, more secure systems narrow into accounts that would then be examined for sensibility post. Even better before then, said fun audit teams raise the cost to compromising all N randomly changing slots on it, much harder to game than a single endpoint. Audit counters by a bit different path than the IT-people problems, does insert time in the process, yet can also payoff by quality, and by rotating participants gaining broader experience with entire codebase, and can even payout from said 10x crypto pot for bugs. Defense in depth, many knobs in the orchestra, turn to set how you want, yet consider before leaving any set too near zero. Good that git monotone hashtrees keys TLS sigs pubkey fingerprints pins TOTP automated lint coverage fuzzing zfs-skein, etc displacing equivalents of legacy telnet CVSROOT, in some OS and projects finally, and that development, being users too, have interest benefit in, and can contribute to that areas and transitions too. Happy hacking in 2021 :)