From nobody Mon Oct 4 04:07:22 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id CE93017D94AA for ; Mon, 4 Oct 2021 04:07:40 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ot1-f54.google.com (mail-ot1-f54.google.com [209.85.210.54]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HN6cr013Wz3JXp; Mon, 4 Oct 2021 04:07:40 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-ot1-f54.google.com with SMTP id l16-20020a9d6a90000000b0053b71f7dc83so19925166otq.7; Sun, 03 Oct 2021 21:07:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Cv1tT1fdg3ADFbOA5GgZvbDo45pVUnK2svjJh2g29OQ=; b=BX/mK1Vk8Tg5YJw6ZFwrxwM4/QgMjBe6Xe/utOEtz6U3lG8U+ERrwArKF8NZG+XrHS lQrDEfcjWBR8mal9i0s2h+Ou7tQ/otvSN93fTzZ7rlzQ3RhPrpRtNmTBVNHr3899uM4K HYQR52wivrjAjRuccXct03oHBXbORW3GUAmWfnZFeGdfJE3yGvgd/KoGXJ8aXmXtvJoQ 2YEfZr5na3QtHRy1UbxC/AxvS5fsqT58r3pIkoROpF8Fe1PimRp24OQ3G+2a/jHw08qu Oc2JYI8vNQbdBugSFxjSkeVV0sc3hX/b+DdVgEVq4hjPr59erqSCcMHKQ3jNNuKcLxiQ Cu0w== X-Gm-Message-State: AOAM532GRbVNu7tftfxNI96ELBVkqkEvBktS8WQx40nH8mZZF0Uaujov yhWQXb180f61HMuMxJFfuwZCwO2x6QhhQ3Vp8kO5nA2Fg0M= X-Google-Smtp-Source: ABdhPJw1bOHZemQrT4rtvitQB0GoRAlItpIlXCxwsq3FhixvLsuLFZUXYmjqWIZYZW9DyAGHypgInSEnQNk8KjCzH4g= X-Received: by 2002:a05:6830:2783:: with SMTP id x3mr7810616otu.371.1633320453470; Sun, 03 Oct 2021 21:07:33 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <6eecc842ba7a37af6b2ffe146dfd91da@mikej.com> <1684681.MCyL5Ev91y@ralph.baldwin.cx> <54018b1b2feaab3b05d7ed406eb8273c@mikej.com> In-Reply-To: From: Alan Somers Date: Sun, 3 Oct 2021 22:07:22 -0600 Message-ID: Subject: Re: witness_lock_list_get: witness exhausted To: Mateusz Guzik Cc: Michael Jung , John Baldwin , FreeBSD Current , owner-freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4HN6cr013Wz3JXp X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.210.54 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [-2.12 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[asomers]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; RCVD_TLS_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; RWL_MAILSPIKE_GOOD(0.00)[209.85.210.54:from]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.12)[-0.122]; RCVD_IN_DNSWL_NONE(0.00)[209.85.210.54:from]; FREEMAIL_TO(0.00)[gmail.com]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Mon, Jan 8, 2018 at 5:31 PM Mateusz Guzik wrote: > > On Tue, Jan 9, 2018 at 12:41 AM, Michael Jung wrote: > > > On 2018-01-08 13:39, John Baldwin wrote: > > > >> On Tuesday, November 28, 2017 02:46:03 PM Michael Jung wrote: > >> > >>> Hi! > >>> > >>> I've recently up'd my processor count on our poudriere box and have > >>> started noticing the error > >>> "witness_lock_list_get: witness exhausted" on the console. The kernel > >>> *DOES NOT* crash but I > >>> thought the report may be useful to someone. > >>> > >>> $ uname -a > >>> FreeBSD poudriere 12.0-CURRENT FreeBSD 12.0-CURRENT #1 r325999: Sun Nov > >>> 19 18:41:20 EST 2017 > >>> mikej@poudriere:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 > >>> > >>> The machine is pretty busy running four poudriere build instances. > >>> > >>> last pid: 76584; load averages: 115.07, 115.96, 98.30 > >>> > >>> up 6+07:32:59 14:44:03 > >>> 763 processes: 117 running, 581 sleeping, 2 zombie, 63 lock > >>> CPU: 59.0% user, 0.0% nice, 40.7% system, 0.1% interrupt, 0.1% idle > >>> Mem: 12G Active, 2003M Inact, 44G Wired, 29G Free > >>> ARC: 28G Total, 11G MFU, 16G MRU, 122M Anon, 359M Header, 1184M Other > >>> 25G Compressed, 32G Uncompressed, 1.24:1 Ratio > >>> > >>> Let me know what additional information I might supply. > >>> > >> > >> This just means that WITNESS stopped working because it ran out of > >> pre-allocated objects. In particular the objects used to track how > >> many locks are held by how many threads: > >> > >> /* > >> * XXX: This is somewhat bogus, as we assume here that at most 2048 > >> threads > >> * will hold LOCK_NCHILDREN locks. We handle failure ok, and we should > >> * probably be safe for the most part, but it's still a SWAG. > >> */ > >> #define LOCK_NCHILDREN 5 > >> #define LOCK_CHILDCOUNT 2048 > >> > >> Probably the '2048' (max number of concurrent threads) needs to scale with > >> MAXCPU. 2048 threads is probably a bit low on big x86 boxes. > >> > > > > > > Thank you for you explanation. We are expanding our ESXi cluster and even > > though with standard edition I can only assign 64 vCPU's to a guest and as > > much > > RAM as I want, I do like to help with edge cases if I can make them occur > > pushing > > boundaries as I can towards additianional improvements in FreeBSD. > > > > Can you apply this and re-run the test? > > https://people.freebsd.org/~mjg/witness.diff > > It bumps the counters to be "high enough" but also starts tracking usage. > If you get > the message again, bump the values even higher. > > Once you get a complete poudriere run which did not result in the problem, > do: > $ sysctl debug.witness.list_used debug.witness.list_max_used > > to dump the actual usage. This is a nice little patch. Can we commit to head? Even better would be if LOCK_CHILDCOUNT could be a tunable. On my largish system, here's what I get shortly after boot: debug.witness.list_max_used: 8432 debug.witness.list_used: 8420 -Alan From nobody Mon Oct 4 05:27:17 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3CD0917E0DE4 for ; Mon, 4 Oct 2021 05:31:46 +0000 (UTC) (envelope-from mikhail.k.holt@gmail.com) Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HN8Tr3dXnz3PvS for ; Mon, 4 Oct 2021 05:31:44 +0000 (UTC) (envelope-from mikhail.k.holt@gmail.com) Received: by mail-pf1-x42a.google.com with SMTP id u7so13468262pfg.13 for ; Sun, 03 Oct 2021 22:31:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:from:subject:message-id:date:user-agent:mime-version; bh=62H0ezgGLGkpR21Om2K43WuFxlML+tEPBwR5D0Bio1s=; b=mko7IGFMapneqGszL3QWWEDSWuPHKlGT5t6WQ6u6XLTX9d4clg7thvHlSHjNBI12Po rWO2kVFNECpGXxDRutmCxFp/Ljja/idjkHBHG0GXc2nRKYhvSvTRZdAGmWM5h3SCxo8H eYtEO/4/Ck25XYnouNhw/5hmLQHeM2jsicvQ1FFArYbk1aRGUirT4ogMUAvykBynuSiB 9nt2py3mH68IlxAhKF8gCTwBJHElTWSy3o3YKsaIfmmdId28O88/7BFz4fW7q1Dco+Zy oaZJaKRS1YeHkTvPONTG7or9lWjCLSkQ6fL1Znk8VaJ07QS1+hIUhJaL/3FHZMpaGoHr 1/0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version; bh=62H0ezgGLGkpR21Om2K43WuFxlML+tEPBwR5D0Bio1s=; b=khF5FTlmYP1iaa+498g96kRzMQQXPGT3FKElaKBU3tEJEQ4X+Rd74Bjao1F0tWLjRG xw8LTMVB7+v+DCOKVd38ac6IrmO5Dp9cbaCrGeZkp+wu5JfwcEFLlkEuY7/RZTQfxxqF +LZPj2vgQpq90BbDQhHrP4Si+hu7t2BKHFUialPhAoWhEkZ0EyWHmKZqItv5Ysfe0t9H CbHgo1XGi8+Ac8SD+D1wgaFugLzQYhjvqHRVKVzf4+Se41s5EC2rrXQ+qde642K1ms0C o1OqwLyMNcxartXgcfNSwpEjMrm6z8xKGSy6/5Ge+DHDvLOiQWu1MM0sUksapA/TzjqA YlBw== X-Gm-Message-State: AOAM532Fxm7VWCKVPp9Xd/tHsqRbseFUdJ8TC73WJu4lVb+n9q5QSxbE gFZruRUJEEixdTNI21FwFAlpx3+390I= X-Google-Smtp-Source: ABdhPJwfRTjc+plyliYbJg7tocQh/iDWHWzB8qHUf1XzgWvhfDVC9/X5Sme2YvOj1MPgDc2HsG9dow== X-Received: by 2002:a65:528a:: with SMTP id y10mr9206474pgp.103.1633325503270; Sun, 03 Oct 2021 22:31:43 -0700 (PDT) Received: from dev05.proftech.net.au (ns3.proftech.net.au. [119.18.12.254]) by smtp.googlemail.com with ESMTPSA id a7sm11920931pfn.150.2021.10.03.22.31.41 for (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sun, 03 Oct 2021 22:31:42 -0700 (PDT) To: freebsd-current@freebsd.org From: Mikhail Holt Subject: 14 stable Guided Root-on-ZFS with 2 disk mirror Message-ID: <615A90B5.7040303@gmail.com> Date: Mon, 4 Oct 2021 16:27:17 +1100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------080607030909020208050104" X-Rspamd-Queue-Id: 4HN8Tr3dXnz3PvS X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=mko7IGFM; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of mikhailkholt@gmail.com designates 2607:f8b0:4864:20::42a as permitted sender) smtp.mailfrom=mikhailkholt@gmail.com X-Spamd-Result: default: False [0.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0: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]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; 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]; FORGED_MUA_THUNDERBIRD_MSGID(4.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::42a:from]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: Y This is a multi-part message in MIME format. --------------080607030909020208050104 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hello All, - Fresh installation of FreeBSD 14 stable from this: FreeBSD-14.0-CURRENT-amd64-20210930-9aa29457d55-249761-memstick.img.xz Took the 'Guided Root-on-ZFS' installation with the following options: - Pool type: Mirror - 2 disks - Partition scheme: GPT (UEFI) - Mirror Swap? No - Encrypt Swap? No - On reboot after the initial installation the system works as it should. The zpool is mirrored and the two disks are synced. - The system will not boot after shutting down the system and disconnecting the first disk. The UEFI BIOS reports that there are no bootable disks. On reconnecting the first disk the system boots and the zpool is re silvered. - It appears that the duplicate EFI partition on second disk is created but the file system is not created and hence the boot files are not installed. - The system will boot from just the second disk after copying the EFI partition from the first disk to the second. - Is this known/expected behaviour? I was expecting to be able to boot from the second disk without having to copy the efi partition. Thanks Mikhail --------------080607030909020208050104-- From nobody Mon Oct 4 11:27:51 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id A5FC617AC233 for ; Mon, 4 Oct 2021 11:27:53 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HNJNn3TKgz4bth; Mon, 4 Oct 2021 11:27:53 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-ot1-x32d.google.com with SMTP id o59-20020a9d2241000000b0054745f28c69so21005198ota.13; Mon, 04 Oct 2021 04:27:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7vJz9ZLoS9Xl9ezAD+E97iNT3DCT9/XveTL0W9nXcw0=; b=fHtgBf6RHi7B42FBzMG+pX4fjxF5AhyKLQtgfzvWjzsf0LSKfMly9LpMF8nDnnKjtl KtaP7jFoA199nMurelAHb9v478sHGYX79CTwzIEbRju/iuOX/c1aic0LhnhMlzUbaRIV x6U+yRRG9pF+9VUg4AzzquQqj8rCOeTVap/68MaGgpcgpTxmOma21BhDR/HZ+z9CH85i FytjzotusNCPv5ZiXpumxaZjN6A5CWYO5QUWZZLcGrQwx0WVTyD0HdkS7L9Laf5EgiRM iYrFs54BJXKVvR1cFnA1YupVj7MhxhKXBepKJUk3WO6CKRszrZ9On/mKXdwvniYFaovn aI3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7vJz9ZLoS9Xl9ezAD+E97iNT3DCT9/XveTL0W9nXcw0=; b=L9anoP+o0vtGEfAyy2GrJEKoxAYPQGVGG5HEz7us0x7u6MlGUQqAgky5o1OobckdZV aEc6LLTNUKoDFdcqy3P9NChpV4uZv6t0de/lZw9fjvYIiuVXDitq4C7GpQmyuZFdKu+W aJ1Td9obEa1kNnDuinK3Cx/yJ46ceUeoI/gDEG/1VwUSElqljryECSDGgtx+8FD4UETT HN4yOj/krxhD8pGQ2lMNOd+5Q5Sh3rKnLKMbwQo3bUc8Znt+ZrWaVlkZfOCfCg+MIggl PaQHQkjOCS9EfUc/Un9yYSLdd3nABW9TC1eXNlrIbqIe3Jfw0zKcY3FF94OqdZUQ4TKb azYg== X-Gm-Message-State: AOAM531R1IMC4Nbee6LzK8I9c0YIoyCSgaCf3HReZWqpYaCP1LQMg+fs nMfwAtE4DnG0hH0+8k5Zq+qpcskyJXOPRBB2oG76wuiN X-Google-Smtp-Source: ABdhPJzzsry/lqfnGKfy9u1hqncqT3cy6pRaPg7roeDAn2TjTRRRUaLrwqEXpevYYUAJLddSoMAHvMgnqLJOVlv2dDU= X-Received: by 2002:a9d:192c:: with SMTP id j44mr8855610ota.302.1633346872296; Mon, 04 Oct 2021 04:27:52 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Received: by 2002:ac9:126d:0:b0:3b4:5824:6a18 with HTTP; Mon, 4 Oct 2021 04:27:51 -0700 (PDT) In-Reply-To: References: <6eecc842ba7a37af6b2ffe146dfd91da@mikej.com> <1684681.MCyL5Ev91y@ralph.baldwin.cx> <54018b1b2feaab3b05d7ed406eb8273c@mikej.com> From: Mateusz Guzik Date: Mon, 4 Oct 2021 13:27:51 +0200 Message-ID: Subject: Re: witness_lock_list_get: witness exhausted To: Alan Somers Cc: Michael Jung , John Baldwin , FreeBSD Current , owner-freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4HNJNn3TKgz4bth X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Just take it and change as you see fit, I don't have time to work on it. On 10/4/21, Alan Somers wrote: > On Mon, Jan 8, 2018 at 5:31 PM Mateusz Guzik wrote: >> >> On Tue, Jan 9, 2018 at 12:41 AM, Michael Jung wrote: >> >> > On 2018-01-08 13:39, John Baldwin wrote: >> > >> >> On Tuesday, November 28, 2017 02:46:03 PM Michael Jung wrote: >> >> >> >>> Hi! >> >>> >> >>> I've recently up'd my processor count on our poudriere box and have >> >>> started noticing the error >> >>> "witness_lock_list_get: witness exhausted" on the console. The >> >>> kernel >> >>> *DOES NOT* crash but I >> >>> thought the report may be useful to someone. >> >>> >> >>> $ uname -a >> >>> FreeBSD poudriere 12.0-CURRENT FreeBSD 12.0-CURRENT #1 r325999: Sun >> >>> Nov >> >>> 19 18:41:20 EST 2017 >> >>> mikej@poudriere:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 >> >>> >> >>> The machine is pretty busy running four poudriere build instances. >> >>> >> >>> last pid: 76584; load averages: 115.07, 115.96, 98.30 >> >>> >> >>> up 6+07:32:59 14:44:03 >> >>> 763 processes: 117 running, 581 sleeping, 2 zombie, 63 lock >> >>> CPU: 59.0% user, 0.0% nice, 40.7% system, 0.1% interrupt, 0.1% >> >>> idle >> >>> Mem: 12G Active, 2003M Inact, 44G Wired, 29G Free >> >>> ARC: 28G Total, 11G MFU, 16G MRU, 122M Anon, 359M Header, 1184M Other >> >>> 25G Compressed, 32G Uncompressed, 1.24:1 Ratio >> >>> >> >>> Let me know what additional information I might supply. >> >>> >> >> >> >> This just means that WITNESS stopped working because it ran out of >> >> pre-allocated objects. In particular the objects used to track how >> >> many locks are held by how many threads: >> >> >> >> /* >> >> * XXX: This is somewhat bogus, as we assume here that at most 2048 >> >> threads >> >> * will hold LOCK_NCHILDREN locks. We handle failure ok, and we >> >> should >> >> * probably be safe for the most part, but it's still a SWAG. >> >> */ >> >> #define LOCK_NCHILDREN 5 >> >> #define LOCK_CHILDCOUNT 2048 >> >> >> >> Probably the '2048' (max number of concurrent threads) needs to scale >> >> with >> >> MAXCPU. 2048 threads is probably a bit low on big x86 boxes. >> >> >> > >> > >> > Thank you for you explanation. We are expanding our ESXi cluster and >> > even >> > though with standard edition I can only assign 64 vCPU's to a guest and >> > as >> > much >> > RAM as I want, I do like to help with edge cases if I can make them >> > occur >> > pushing >> > boundaries as I can towards additianional improvements in FreeBSD. >> > >> >> Can you apply this and re-run the test? >> >> https://people.freebsd.org/~mjg/witness.diff >> >> It bumps the counters to be "high enough" but also starts tracking usage. >> If you get >> the message again, bump the values even higher. >> >> Once you get a complete poudriere run which did not result in the >> problem, >> do: >> $ sysctl debug.witness.list_used debug.witness.list_max_used >> >> to dump the actual usage. > > This is a nice little patch. Can we commit to head? Even better > would be if LOCK_CHILDCOUNT could be a tunable. On my largish system, > here's what I get shortly after boot: > > debug.witness.list_max_used: 8432 > debug.witness.list_used: 8420 > > -Alan > -- Mateusz Guzik From nobody Tue Oct 5 21:28:32 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 84F8A12D6882 for ; Tue, 5 Oct 2021 21:28:32 +0000 (UTC) (envelope-from pstef@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HP9gN2N3qz3hVm; Tue, 5 Oct 2021 21:28:32 +0000 (UTC) (envelope-from pstef@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1633469312; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=0h9/2RJUXq1LAk+p8/Gy7iZKRwjr1x/VG40Ks65X5xU=; b=Woz2xLtpVBp2islhscMDGwUhEQupH+GbUikPN6XO/i+wvb2E+j4V0b7bmr5xOcR+RVgd5Z gjKX8S2pv32PYnB//21S3fNgU2AXT8OKx8kfEZeEMot0OpFJx1fPaCOAa7S/CmCsrmufS3 pHEcagwGILpsnRPAorQh8HYy/1Ls8NhPs0mrpp5FBV5lY743i5CoE7AT/N07PFG+z7+7AC yXx7J5TqQi6DOD79FPwkwh/0guGDUE4UrwJ4fXOITRDZhkLlXzkdqd3Mp0V3EiflGG9woO uzkwd2a4IOxtyGZqMsfSxu2z6rTt82pw+2kY7SRn0L6GMZ1pq8Swhpp9Gi7nxw== Received: by freefall.freebsd.org (Postfix, from userid 1403) id 10448F0B3; Tue, 5 Oct 2021 21:28:32 +0000 (UTC) Date: Tue, 5 Oct 2021 21:28:32 +0000 From: "Piotr P. Stefaniak" To: Baptiste Daroussin Cc: daniel@morante.net, freebsd-current@freebsd.org Subject: Re: [HEADSUP] making /bin/sh the default shell for root Message-ID: References: <20210922083645.4vnoajyvwq6wfhdf@aniel.nours.eu> <20210922093236.azun2pqciabo3fem@aniel.nours.eu> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20210922093236.azun2pqciabo3fem@aniel.nours.eu> ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1633469312; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=0h9/2RJUXq1LAk+p8/Gy7iZKRwjr1x/VG40Ks65X5xU=; b=JB0nyQRMYXDGrgGCDt/XQ4lOcmJJ4CYJll2jN1W2Z5LfWHAhQaY9g4+pACx82cH0EL2Tzz WIbrec0PAEW42+gZF4/UL0sD/cf9AFV3IiCwvZUeXIn2fOqK0oQW+O3TPCaIUNZ9jg7gd7 jb7fyDzMeF1TyKT1xyYBvn4+nkHYbhsTdVxH9oWk5/brn/A1ShnDKnHqlzCf5SVQXIVCGR m7UtgJYL+2lU9/6Gzg7/giGeASL+RIdBs/9/N2Ugjg3vJk9wlC/K2iMVcCnK/jQsdoZpj/ ZhnwEYLGbdzsgt0HPj9EPPvyem0p3rcB5YAjgDxYld5R3YjmUkjo09cMDqlJ1g== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1633469312; a=rsa-sha256; cv=none; b=LDKAluL6kZFYtw0slkDUwhz3wUewFlRlAh9qYukjEZguEwzrpz/Mf4fB5xEJpOIaQh0PYT +j8cgssENBKarUcd33n5Bhq9Mr3DFD6fAF6gbNUOicTP6zBM+EDLPBUhzC4PHyihSz4pYE gPh4OcN2a8xbl7bz7y9HO8Ww3Tbty5agSKkZdk9UJZD9/xHWFCMUqT3Xy0OlqsPlHUvP3H tyEBqxsboLIGYWHxTLgctd3nxOE+pYUNGkooTG8M4gIc433S0+5nDGxjwXE6+m3BVvN9BH pDyJdj0a27EC4/W/3s82Q1Mk3piz/4fMra6KsH0rPTjIgZJSB7XtqCKbYEar2g== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On 2021-09-22 11:32:36, Baptiste Daroussin wrote: >On Wed, Sep 22, 2021 at 05:19:38AM -0400, Daniel Morante via freebsd-current wrote: >> Will history/completion continue to work the same way? (for example typing >> part of the command, pressing UP and having it complete based on history) > >No, this is a csh specific behaviour. (not it can probably be doable via >.shrc, but I haven't checked) I think that it can be recreated in sh. This works for me: bind ^[[A ed-search-prev-history bind ^[[B ed-search-next-history I believe ^V should work as well as ^[[A or better. That is not to claim anything about future defaults. This is just a tip. From nobody Wed Oct 6 07:56:15 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 8F49D17E19CC; Wed, 6 Oct 2021 07:56:16 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HPRbh3hDSz3wCp; Wed, 6 Oct 2021 07:56:16 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: from aniel.nours.eu (nours.eu [IPv6:2001:41d0:8:3a4d::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: bapt) by smtp.freebsd.org (Postfix) with ESMTPSA id 47BA69DCA; Wed, 6 Oct 2021 07:56:16 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: by aniel.nours.eu (Postfix, from userid 1001) id 080A8461E0; Wed, 6 Oct 2021 09:56:15 +0200 (CEST) Date: Wed, 6 Oct 2021 09:56:15 +0200 From: Baptiste Daroussin To: freebsd-current Cc: freebsd-ports Subject: Re: Bash Static broken with new ncurses update on current Message-ID: <20211006075615.ngxxbyxfq2nmcadl@aniel.nours.eu> References: List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-ThisMailContainsUnwantedMimeParts: N On Tue, Oct 05, 2021 at 11:46:45AM -0700, Manfred Antar (KN6KBS) wrote: > After update to current world on 10/5/2021 bash static is broken: > > cc -L./builtins -L/usr/local/lib -L/usr/local/lib -L./lib/glob -L./lib/tilde -L./lib/sh -L/usr/local/lib -fstack-protector-strong -fuse-ld=bfd -static -O2 -pipe -DLIBICONV_PLUG -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing -static -o bash shell.o eval.o y.tab.o general.o make_cmd.o print_cmd.o dispose_cmd.o execute_cmd.o variables.o copy_cmd.o error.o expr.o flags.o jobs.o subst.o hashcmd.o hashlib.o mailcheck.o trap.o input.o unwind_prot.o pathexp.o sig.o test.o version.o alias.o array.o arrayfunc.o assoc.o braces.o bracecomp.o bashhist.o bashline.o list.o stringlib.o locale.o findcmd.o redir.o pcomplete.o pcomplib.o syntax.o xmalloc.o -lbuiltins -lglob -lsh -lreadline -lhistory -lncursesw -ltilde -L/usr/local/lib > /usr/local/bin/ld.bfd: ./lib/sh/libsh.a(tmpfile.o): in function `sh_mktmpname': > tmpfile.c:(.text+0x85): warning: warning: mktemp() possibly used unsafely; consider using mkstemp() > /usr/local/bin/ld.bfd: /usr/local/lib/libreadline.a(display.o): in function `update_line': > display.c:(.text+0x4654): undefined reference to `tgoto' > /usr/local/bin/ld.bfd: display.c:(.text+0x4664): undefined reference to `tputs' > /usr/local/bin/ld.bfd: display.c:(.text+0x48e1): undefined reference to `tputs' > /usr/local/bin/ld.bfd: display.c:(.text+0x48ff): undefined reference to `tputs' > /usr/local/bin/ld.bfd: display.c:(.text+0x4a62): undefined reference to `tgoto' > /usr/local/bin/ld.bfd: display.c:(.text+0x4a74): undefined reference to `tputs' > /usr/local/bin/ld.bfd: display.c:(.text+0x4b5d): undefined reference to `tputs' > /usr/local/bin/ld.bfd: display.c:(.text+0x4b8f): undefined reference to `tputs' > /usr/local/bin/ld.bfd: display.c:(.text+0x4bc7): undefined reference to `tputs' > /usr/local/bin/ld.bfd: /usr/local/lib/libreadline.a(display.o): in function `_rl_clear_to_eol': > display.c:(.text+0x4c15): undefined reference to `tputs' > /usr/local/bin/ld.bfd: /usr/local/lib/libreadline.a(display.o):display.c:(.text+0x4cf3): more undefined references to `tputs' follow > /usr/local/bin/ld.bfd: /usr/local/lib/libreadline.a(terminal.o): in function `_rl_get_screen_size': > terminal.c:(.text+0xd0): undefined reference to `tgetnum' > /usr/local/bin/ld.bfd: terminal.c:(.text+0x108): undefined reference to `tgetnum' > /usr/local/bin/ld.bfd: /usr/local/lib/libreadline.a(terminal.o): in function `_rl_init_terminal_io': > terminal.c:(.text+0x36d): undefined reference to `tgetent' > /usr/local/bin/ld.bfd: terminal.c:(.text+0x39b): undefined reference to `tgetstr' > /usr/local/bin/ld.bfd: terminal.c:(.text+0x5b9): undefined reference to `PC' > /usr/local/bin/ld.bfd: terminal.c:(.text+0x5cc): undefined reference to `BC' > /usr/local/bin/ld.bfd: terminal.c:(.text+0x5d7): undefined reference to `UP' > /usr/local/bin/ld.bfd: terminal.c:(.text+0x603): undefined reference to `PC' > /usr/local/bin/ld.bfd: terminal.c:(.text+0x611): undefined reference to `BC' > /usr/local/bin/ld.bfd: terminal.c:(.text+0x61f): undefined reference to `UP' > /usr/local/bin/ld.bfd: terminal.c:(.text+0x63e): undefined reference to `tgetflag' > /usr/local/bin/ld.bfd: terminal.c:(.text+0x64f): undefined reference to `tgetflag' > /usr/local/bin/ld.bfd: terminal.c:(.text+0x6a3): undefined reference to `tgetflag' > /usr/local/bin/ld.bfd: /usr/local/lib/libreadline.a(terminal.o): in function `_rl_backspace': > terminal.c:(.text+0xa43): undefined reference to `tputs' > /usr/local/bin/ld.bfd: terminal.c:(.text+0xa62): undefined reference to `tputs' > /usr/local/bin/ld.bfd: /usr/local/lib/libreadline.a(terminal.o): in function `_rl_cr': > terminal.c:(.text+0xb37): undefined reference to `tputs' > /usr/local/bin/ld.bfd: /usr/local/lib/libreadline.a(terminal.o): in function `rl_ding': > terminal.c:(.text+0xb78): undefined reference to `tputs' > /usr/local/bin/ld.bfd: /usr/local/lib/libreadline.a(terminal.o): in function `_rl_standout_on': > terminal.c:(.text+0xbd6): undefined reference to `tputs' > /usr/local/bin/ld.bfd: /usr/local/lib/libreadline.a(terminal.o):terminal.c:(.text+0xc06): more undefined references to `tputs' follow > cc: error: linker command failed with exit code 1 (use -v to see invocation) > *** [bash] Error code 1 > > make[2]: stopped in /usr/ports/shells/bash/work/bash-5.1 > 1 error > > make[2]: stopped in /usr/ports/shells/bash/work/bash-5.1 > ===> Compilation failed unexpectedly. > Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to > the maintainer. > *** Error code 1 > > Stop. > make[1]: stopped in /usr/ports/shells/bash > *** Error code 1 > > Stop. > make: stopped in /usr/ports/shells/bash > > Fixed, thank you for reporting Bapt From nobody Wed Oct 6 10:23:04 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id C320312BD7D2 for ; Wed, 6 Oct 2021 10:23:08 +0000 (UTC) (envelope-from gardask@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 4HPVs80GXMz4mNq for ; Wed, 6 Oct 2021 10:23:08 +0000 (UTC) (envelope-from gardask@gmail.com) Received: by mail-wr1-x42c.google.com with SMTP id u18so7293359wrg.5 for ; Wed, 06 Oct 2021 03:23:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=TmU4olCF6TJne9sSsPJCKTyFkN1EaN1RcReAqnLJOmU=; b=huemcTG4R32K6w4uLp5/B7HDhjJK5BcO7lzwm/XnqsQdjUIx6Evmjyzebcmekk0LjF xrjgSgy4crxMsufE/4U37T3tsmrrr5THi/fPw11KozEoAF3aTsI/Q4imAUNQGBg4ERYj eGBjCn0stH1pN8yEyCMw7i387A0DPm5N8gPVRfOaxp+GjSAJ1HRxc6qJQdkK8YfvqTzW X28gl5bl+j9jY+RWRZuqrDigCUNfl7yxXfMhOJgnDN+1iPb/9GNaYBGKJjuKnMGD5mT/ N/ofA4dcr/9E/9DX/pICktMj++Q6E450E6pgteGC2lsvk9irAyLf2gR3J9wh5oBNna8F MN2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=TmU4olCF6TJne9sSsPJCKTyFkN1EaN1RcReAqnLJOmU=; b=GABLpJK5EBA8OFvqlHUqknkXIA3oWW0QTswLHCZmyU0eq0EprU3bWM1uObD5yVssgv PD8IWTH0WoL3a3sdS28i5zShCuxtOP09QS8E3P0w5/dg7dm3T8yrEoeEb/1T174XxJkh bfzBTs4NXxXyJ/LjrZ3uVFNHAiaPYgXtNyHirdn08Xsqg5Lczfb4a+7foIaq4FQaHoik D1E2Q8UErptFBmgCc5YSsXqTEI5r0A/lz2oVxIzkLH7ROV7s4ZImVmkM+Rrf9BNaD6jj Xn5GtOK00fPninjV80rjfYDI3rOU0lELgdtuKy645FaHFyVDnElmwqQ+sci0Y6D/+do2 jg8Q== X-Gm-Message-State: AOAM533luoKMFsKJw8VYUuNEqFyqxYAZKpxGDwQVZX4rZuQSkOEav+F0 n+uU8a947UySQHPEQaw5XM/7kAwNSA8= X-Google-Smtp-Source: ABdhPJwSZqT2eyt11sAcaxcaFSaPoyYEjmXkOfWnn45qZjCJAntzhDMjgBSZX0WcVXgssppQ+GoZCg== X-Received: by 2002:adf:a411:: with SMTP id d17mr24001618wra.393.1633515786640; Wed, 06 Oct 2021 03:23:06 -0700 (PDT) Received: from [10.0.30.5] ([31.47.99.1]) by smtp.gmail.com with ESMTPSA id h3sm13339527wro.42.2021.10.06.03.23.05 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 06 Oct 2021 03:23:06 -0700 (PDT) To: freebsd-current@freebsd.org From: Karel Gardas Subject: make buildworld broken on RISC-V. Message-ID: <58e693bc-93ea-866e-2bd2-98b6b7228530@gmail.com> Date: Wed, 6 Oct 2021 12:23:04 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4HPVs80GXMz4mNq X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=huemcTG4; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of gardask@gmail.com designates 2a00:1450:4864:20::42c as permitted sender) smtp.mailfrom=gardask@gmail.com 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]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; SH_EMAIL_DBL_DONT_QUERY_IPS(0.00)[0.0.0.8:email]; 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]; DBL_PROHIBIT(0.00)[0.0.0.8:email]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::42c:from]; NEURAL_SPAM_SHORT(1.00)[1.000]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N Hello, I'm using 14-CURRENT oprovided qcow2 image from September 30 in qemu-system-risc64. It runs fine so I'm testing it with attempting make buildworld. This unfortunately fails with: ===> lib/clang/headers (includes) [Creating objdir /usr/obj/usr/src/riscv.riscv64/lib/clang/headers...] clang-tblgen -gen-arm-bf16 -I /usr/src/contrib/llvm-project/clang/include/clang/Basic -d arm_bf16.h.d -o arm_bf16.h /usr/src/contrib/llvm-project/clang/include/clang/Basic/arm_bf16.td ELF binary type "0" not known. /usr/obj/usr/src/riscv.riscv64/tmp/legacy/usr/sbin/clang-tblgen: ELF�Т: not found /usr/obj/usr/src/riscv.riscv64/tmp/legacy/usr/sbin/clang-tblgen: @h�a@8: not found /usr/obj/usr/src/riscv.riscv64/tmp/legacy/usr/sbin/clang-tblgen: @@@0�: not found /usr/obj/usr/src/riscv.riscv64/tmp/legacy/usr/sbin/clang-tblgen: �: not found /usr/obj/usr/src/riscv.riscv64/tmp/legacy/usr/sbin/clang-tblgen: 1: Syntax error: "(" unexpected /usr/obj/usr/src/riscv.riscv64/tmp/legacy/usr/sbin/clang-tblgen: 5: Syntax error: Error in command substitution *** Error code 2 Stop. make[5]: stopped in /usr/src/lib/clang/headers *** Error code 1 Stop. make[4]: stopped in /usr/src/lib/clang *** Error code 1 Stop. make[3]: stopped in /usr/src/lib *** Error code 1 Stop. make[2]: stopped in /usr/src 370.58 real 114.97 user 258.16 sys *** Error code 1 Stop. make[1]: stopped in /usr/src *** Error code 1 Stop. make: stopped in /usr/src I'm not sure which from available clang-tblgen is invoked: # find / -type f -name 'clang-tblgen'/usr/obj/usr/src/riscv.riscv64/tmp/legacy/bin/clang-tblgen /usr/obj/usr/src/riscv.riscv64/tmp/obj-tools/usr.bin/clang/clang-tblgen/clang-tblgen but both seems to be reasonable file types: root@freebsd:/usr/src/lib/clang/headers # file /usr/obj/usr/src/riscv.riscv64/tmp/legacy/bin/clang-tblgen /usr/obj/usr/src/riscv.riscv64/tmp/legacy/bin/clang-tblgen: ELF 64-bit LSB executable, UCB RISC-V, version 1 (SYSV), statically linked, FreeBSD-style, not stripped root@freebsd:/usr/src/lib/clang/headers # file /usr/obj/usr/src/riscv.riscv64/tmp/obj-tools/usr.bin/clang/clang-tblgen/clang-tblgen /usr/obj/usr/src/riscv.riscv64/tmp/obj-tools/usr.bin/clang/clang-tblgen/clang-tblgen: ELF 64-bit LSB executable, UCB RISC-V, version 1 (SYSV), statically linked, FreeBSD-style, not stripped Is there any trick how to solve this issue? Thanks, Karel From nobody Wed Oct 6 13:37:26 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 16E2E17E22DA for ; Wed, 6 Oct 2021 13:37:38 +0000 (UTC) (envelope-from mhorne@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HPb9Y73FQz3M6g for ; Wed, 6 Oct 2021 13:37:37 +0000 (UTC) (envelope-from mhorne@freebsd.org) Received: from mail-yb1-f174.google.com (mail-yb1-f174.google.com [209.85.219.174]) (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: mhorne) by smtp.freebsd.org (Postfix) with ESMTPSA id CDE79CAFA for ; Wed, 6 Oct 2021 13:37:37 +0000 (UTC) (envelope-from mhorne@freebsd.org) Received: by mail-yb1-f174.google.com with SMTP id r1so5443864ybo.10 for ; Wed, 06 Oct 2021 06:37:37 -0700 (PDT) X-Gm-Message-State: AOAM533Ij04Y9FxIYaUKjdNC8TTR7FpZJzkE+RaVi6FSKbB+38Q1L9gm Xfwi9XF1Q939TKMbbLjsBxhVY2idCVR+S2rrzXc= X-Google-Smtp-Source: ABdhPJzztYNae+x2o3iaowJg6iUJpP/PS7AOakf0lNZTAdsMepySqR7E215PfoDuA8wkatG1/+CIv61jA91ZG+ypRSw= X-Received: by 2002:a25:734b:: with SMTP id o72mr11878267ybc.356.1633527457247; Wed, 06 Oct 2021 06:37:37 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <58e693bc-93ea-866e-2bd2-98b6b7228530@gmail.com> In-Reply-To: <58e693bc-93ea-866e-2bd2-98b6b7228530@gmail.com> From: Mitchell Horne Date: Wed, 6 Oct 2021 10:37:26 -0300 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: make buildworld broken on RISC-V. To: Karel Gardas Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-ThisMailContainsUnwantedMimeParts: N On Wed, Oct 6, 2021 at 7:23 AM Karel Gardas wrote: > > > Hello, > > I'm using 14-CURRENT oprovided qcow2 image from September 30 in > qemu-system-risc64. It runs fine so I'm testing it with attempting make > buildworld. This unfortunately fails with: > > =3D=3D=3D> lib/clang/headers (includes) > [Creating objdir /usr/obj/usr/src/riscv.riscv64/lib/clang/headers...] > clang-tblgen -gen-arm-bf16 -I > /usr/src/contrib/llvm-project/clang/include/clang/Basic -d arm_bf16.h.d > -o arm_bf16.h > /usr/src/contrib/llvm-project/clang/include/clang/Basic/arm_bf16.td > ELF binary type "0" not known. > /usr/obj/usr/src/riscv.riscv64/tmp/legacy/usr/sbin/clang-tblgen: ELF=EF= =BF=BD=D0=A2: > not found > /usr/obj/usr/src/riscv.riscv64/tmp/legacy/usr/sbin/clang-tblgen: @h=EF=BF= =BDa@8: > not found > /usr/obj/usr/src/riscv.riscv64/tmp/legacy/usr/sbin/clang-tblgen: @@@0=EF= =BF=BD: > not found > /usr/obj/usr/src/riscv.riscv64/tmp/legacy/usr/sbin/clang-tblgen: =EF=BF= =BD: not > found > /usr/obj/usr/src/riscv.riscv64/tmp/legacy/usr/sbin/clang-tblgen: 1: > Syntax error: "(" unexpected > /usr/obj/usr/src/riscv.riscv64/tmp/legacy/usr/sbin/clang-tblgen: 5: > Syntax error: Error in command substitution > *** Error code 2 > > Stop. > make[5]: stopped in /usr/src/lib/clang/headers > *** Error code 1 > > Stop. > make[4]: stopped in /usr/src/lib/clang > *** Error code 1 > > Stop. > make[3]: stopped in /usr/src/lib > *** Error code 1 > > Stop. > make[2]: stopped in /usr/src > 370.58 real 114.97 user 258.16 sys > *** Error code 1 > > Stop. > make[1]: stopped in /usr/src > *** Error code 1 > > Stop. > make: stopped in /usr/src > > > I'm not sure which from available clang-tblgen is invoked: > > # find / -type f -name > 'clang-tblgen'/usr/obj/usr/src/riscv.riscv64/tmp/legacy/bin/clang-tblgen > /usr/obj/usr/src/riscv.riscv64/tmp/obj-tools/usr.bin/clang/clang-tblgen/c= lang-tblgen > > > but both seems to be reasonable file types: > > root@freebsd:/usr/src/lib/clang/headers # file > /usr/obj/usr/src/riscv.riscv64/tmp/legacy/bin/clang-tblgen > /usr/obj/usr/src/riscv.riscv64/tmp/legacy/bin/clang-tblgen: ELF 64-bit > LSB executable, UCB RISC-V, version 1 (SYSV), statically linked, > FreeBSD-style, not stripped > root@freebsd:/usr/src/lib/clang/headers # file > /usr/obj/usr/src/riscv.riscv64/tmp/obj-tools/usr.bin/clang/clang-tblgen/c= lang-tblgen > /usr/obj/usr/src/riscv.riscv64/tmp/obj-tools/usr.bin/clang/clang-tblgen/c= lang-tblgen: > ELF 64-bit LSB executable, UCB RISC-V, version 1 (SYSV), statically > linked, FreeBSD-style, not stripped > > > Is there any trick how to solve this issue? > This has been reported here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D258358 There is a workaround provided which allows the build to proceed, see comment #4 and #6. Cheers, Mitchell > Thanks, > Karel > From nobody Thu Oct 7 02:16:43 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 5233412D4258 for ; Thu, 7 Oct 2021 02:16:53 +0000 (UTC) (envelope-from felix@palmen-it.de) Received: from stef.palmen-it.de (stef.palmen-it.de [IPv6:2001:470:1f0b:bbb:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HPw1c4DJKz4h3F for ; Thu, 7 Oct 2021 02:16:52 +0000 (UTC) (envelope-from felix@palmen-it.de) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=palmen-it.de; s=20200414; h=Content-Type:MIME-Version:Message-ID:Subject:To :From:Date:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=XjGBawym3GFWmNI5HDEjRFek3FXZ+ROjdiLgoaA4qbE=; b=dYH7kIrATZ3FilftTsSDx7vphS uXQgL+pHSMYGUj8YlVT6eE5P+ejvz4+KX2EmYH6HZolKP3xN9SR9O/2QP9OKnEXhDYHcQhZseeiCn tiTq5APo+58f1AEfj9HRh9Wex+Y/TG59HjP7ths3sJqLX7pTZNmV1YIw0tUTX9+6RJkln29Iw1YV5 MWMoNcfCqeSymGV+ST+AIgnAQLwiCLeWv37IkDDJ4nP5fw+zCtwuDs3EVvwzJAYfavB31vSNbaIcB KQ3rt0TZTN83+o5rV49LgzVG2EFBV5Kb+ROOaaw5jdfsY//FQRM9dOAWWno+mIi/6U3xL1qZI9PoO qhybqhBQ==; Received: from [192.168.71.101] (helo=mail.home.palmen-it.de) by stef.palmen-it.de with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mYIxh-002XSB-D9 for freebsd-current@freebsd.org; Thu, 07 Oct 2021 04:16:45 +0200 Received: from nexus.home.palmen-it.de ([192.168.99.2]) by mail.home.palmen-it.de with esmtpsa (TLS1.3) tls TLS_CHACHA20_POLY1305_SHA256 (Exim 4.94.2 (FreeBSD)) (envelope-from ) id 1mYIxh-000J7s-0Z for freebsd-current@freebsd.org; Thu, 07 Oct 2021 02:16:45 +0000 Date: Thu, 7 Oct 2021 04:16:43 +0200 From: Felix Palmen To: freebsd-current@freebsd.org Subject: Writing large build logs to NFS extremely slow? Message-ID: <20211007021643.bwglyvrswk2nm3fl@nexus.home.palmen-it.de> Mail-Followup-To: freebsd-current@freebsd.org X-Face: /1K@t"h.}e~pR@]c7HorQ!T`F^RJCa'BCr#e>IKA{>C/9OTGB4|xh"y2{?1Z5M i2w"AH^pN_LlHR^{+f',_Np~;.B;!M/bL}*qk]p5*r7F5vW};{:@4u5S?T&f0$7BJ-71Q5SV]:v$`5 A0[DZ:=?S52x8HJ~5@^P_\T@MsjG{R( Organization: palmen-it.de List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="6cllmsfym7gt7d4d" Content-Disposition: inline User-Agent: NeoMutt/20210205 X-Rspamd-Queue-Id: 4HPw1c4DJKz4h3F X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org; dkim=pass header.d=palmen-it.de header.s=20200414 header.b=dYH7kIrA; dmarc=pass (policy=none) header.from=palmen-it.de; spf=pass (mx1.freebsd.org: domain of felix@palmen-it.de designates 2001:470:1f0b:bbb:1::1 as permitted sender) smtp.mailfrom=felix@palmen-it.de X-Spamd-Result: default: False [-6.20 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[palmen-it.de:s=20200414]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2001:470:1f0b:bbb:1::1]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_DN_NONE(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROMTLD(0.00)[]; DWL_DNSWL_LOW(-1.00)[palmen-it.de:dkim]; DKIM_TRACE(0.00)[palmen-it.de:+]; DMARC_POLICY_ALLOW(-0.50)[palmen-it.de,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_TLS_ALL(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[2001:470:1f0b:bbb:1::1:from] X-ThisMailContainsUnwantedMimeParts: N --6cllmsfym7gt7d4d Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi all, I use a -CURRENT bhyve vm for testing port builds with poudriere. As this vm is only running when needed, but I want to always have access to the build logs, I use NFS to mount /usr/local/poudriere/data/logs from the host. I noticed some few ports take ridiculously long to build while barely using any CPU time at all. On a closer look, that's all ports producing a lot of compiler (warning) output, e.g. gcc, gnutls, gtk2, =E2=80=A6 So I assume appending to a large file via NFS gets slower and slower. Is there any mount option I could try to fix this? Right now I only have `nolockd`, I also tried `noncontigwr` which didn't change anything. Thinking about alternatives to NFS, are there any news for client-side 9p virtfs? I found which still builds with a few minor adaptions, but trying to mount a 9p share freezes the machine. Would you suggest a different mailing list to ask? BR, Felix --=20 Dipl.-Inform. Felix Palmen ,.//.......... {web} http://palmen-it.de {jabber} [see email] ,//palmen-it.de {pgp public key} http://palmen-it.de/pub.txt // """"""""""" {pgp fingerprint} A891 3D55 5F2E 3A74 3965 B997 3EF2 8B0A BC02 DA2A --6cllmsfym7gt7d4d Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEqJE9VV8uOnQ5ZbmXPvKLCrwC2ioFAmFeWHQACgkQPvKLCrwC 2ipEiggAoQD5nkmj/aRlDAZGE5zhFH7jQajcsCnalr6UZZ43ioogVTVkc8K2B+Zh ZsO1SUjxFdbsWLWJbjYQUh4+XxVtkUbP1aUw3+jYgkBqk8Ftap6UDEQZPjNzvmSf yxun9k6ywOwfuCzIZtqWUDe9ZgpNQAIG9XZLu3A0cqIzVSLdHjuLDZ5B8iIMFyts E78NMiMM3Dm/Cahl/YaJFJlum/JGz5niDJtoudYl/qcfzNi1L7eOUejcuwRJu9hp JCiXh2Ni6zcyasznzKQ4kcPFMH0+a3Bj5TQiKdLO2uuU4mBiFCRf/i4RY/bJJsOm 90CrCEDWaisJ6iygHJivPMuwDb041g== =ZLQ3 -----END PGP SIGNATURE----- --6cllmsfym7gt7d4d-- From nobody Thu Oct 7 07:42:32 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4557012D6F40 for ; Thu, 7 Oct 2021 07:43:10 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: from mail-ua1-x931.google.com (mail-ua1-x931.google.com [IPv6:2607:f8b0:4864:20::931]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HQ3G53yPNz3stD for ; Thu, 7 Oct 2021 07:43:09 +0000 (UTC) (envelope-from m.e.sanliturk@gmail.com) Received: by mail-ua1-x931.google.com with SMTP id i8so3640394uae.7 for ; Thu, 07 Oct 2021 00:43:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=c9KjjB95U6XLqhGIRt3PkrrzASD007oQN2sfj3BnpCI=; b=B3XOnlhVIDoCh4Z/cYJQo95qtb1cUbRvVBCjjWhofvgFbOTfAG+XztrfUysLvkZQGS gTHSnp+NhUT7Q0wdjjwEV9DzSAPZfW0adPfX+bc1X/VwKT2TtDsvFEZYqj9zAJwaCA5n L0O3OMBpddBijQFv9D3Q4h587oKzheIetMGVLP9gN6j6qEUZ9gptjdnuJdVvjXjKRLI6 4uDyAoyXUqrioCfrWjfLJFxP6emb06EDLAQHxKhusM66MzIn9k7lq/fHqQ1XdDkfFDov NVK5E74ddJS8IX2mOCh9Ij8iusiAogRPYVeI6wfA1CiJcSF5wSezsTmywt+OUSSIggYD Nc6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=c9KjjB95U6XLqhGIRt3PkrrzASD007oQN2sfj3BnpCI=; b=6unNYEpnFZWvbcIOkGoSMDv0qFIJ1Mr1j2Ed+nRLiohT8gW0rUURo5v/S41jFx0xU7 IO3ov9TBfNgzw9v6+4vL5NDuv1q6UrVvMHsU1Iqe1fBNm7Dhv/r2WXU7Izg/o/Y1jYri yXiKUVUqlQrxjcBwaB+c2uLz+lX8ISCeDyRaQ0LNb/e86KGsmHjnKAXYhREuJ40mOtsz VieRut5sZ0m1BVaKRBEj9BvDAV88hiLOSM+SEhedk26Q6Q7f2+98lPb3k5gPsZUeW2LI ZdGaddp8vFmoszwgbHxYxNV9WX7qP05Mcx0Gj7Co1cqzwJ0ped55t8ppW+bB/AeBCqL5 204w== X-Gm-Message-State: AOAM531k4nllP7n/yeSnSA7HfgXQHB63QK7/FAkDje6lH63Ia9ArvGes NSnZu2l7yRlX2D2q3V4W7BOWCFFJRDj/AQS2HtfXG4JKZ58= X-Google-Smtp-Source: ABdhPJzNL12t5xaGacZj13ol/sbIA9jJrJyXE/IHJ4mu6TzY13aQFhx2EfjCAJU+JGpjFTrYQATXgzoAFiuJZbzJcrk= X-Received: by 2002:ab0:6dd0:: with SMTP id r16mr2923901uaf.82.1633592588715; Thu, 07 Oct 2021 00:43:08 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <20211007021643.bwglyvrswk2nm3fl@nexus.home.palmen-it.de> In-Reply-To: <20211007021643.bwglyvrswk2nm3fl@nexus.home.palmen-it.de> From: Mehmet Erol Sanliturk Date: Thu, 7 Oct 2021 10:42:32 +0300 Message-ID: Subject: Re: Writing large build logs to NFS extremely slow? To: FreeBSD Current Content-Type: multipart/alternative; boundary="000000000000f54a9405cdbe6906" X-Rspamd-Queue-Id: 4HQ3G53yPNz3stD X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=B3XOnlhV; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of mesanliturk@gmail.com designates 2607:f8b0:4864:20::931 as permitted sender) smtp.mailfrom=mesanliturk@gmail.com X-Spamd-Result: default: False [-1.59 / 15.00]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; URI_COUNT_ODD(1.00)[1]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.59)[-0.590]; FROM_EQ_ENVFROM(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::931:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: Y --000000000000f54a9405cdbe6906 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Oct 7, 2021 at 5:17 AM Felix Palmen wrote: > Hi all, > > I use a -CURRENT bhyve vm for testing port builds with poudriere. As > this vm is only running when needed, but I want to always have access to > the build logs, I use NFS to mount /usr/local/poudriere/data/logs from > the host. > > I noticed some few ports take ridiculously long to build while barely > using any CPU time at all. On a closer look, that's all ports producing > a lot of compiler (warning) output, e.g. gcc, gnutls, gtk2, =E2=80=A6 > > So I assume appending to a large file via NFS gets slower and slower. Is > there any mount option I could try to fix this? Right now I only have > `nolockd`, I also tried `noncontigwr` which didn't change anything. > > Thinking about alternatives to NFS, are there any news for client-side > 9p virtfs? I found which > still builds with a few minor adaptions, but trying to mount a 9p share > freezes the machine. > > Would you suggest a different mailing list to ask? > > BR, Felix > > -- > Dipl.-Inform. Felix Palmen ,.//.......... > {web} http://palmen-it.de {jabber} [see email] ,//palmen-it.de > {pgp public key} http://palmen-it.de/pub.txt // """"""""""" > {pgp fingerprint} A891 3D55 5F2E 3A74 3965 B997 3EF2 8B0A BC02 DA2A > I have encountered such cases previously , but I am not able to remember which parameters I have used to solve this problem , because I am not using the FreeBSD server now . A similar problem occurs also in the Linux NFS server. The problem is caused mainly by NFS definition parameters . If you study NFS definition parameters one by one , I think you will be able to find which one is effective . My opinion is the one setting is "write directly to disk" , i.e. , "do not use the cache" . In the "write directly to disk" case , without completion of a write , the computer in use is waiting for completion of previous write operation before writing a new record . This is useful in case of abrupt program terminations because every record is written into the disk file , by consuming more time . In the cache use case , time is not consumed much but the last written records are lost in an abrupt program termination . My understanding from your question is this . Mehmet Erol Sanliturk --000000000000f54a9405cdbe6906-- From nobody Thu Oct 7 19:28:44 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 5314017E30BF for ; Thu, 7 Oct 2021 19:28:54 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.protected-networks.net (mail.protected-networks.net [202.12.127.228]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.protected-networks.net", Issuer "R3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HQLwP3MkZz4jSK for ; Thu, 7 Oct 2021 19:28:53 +0000 (UTC) (envelope-from imb@protected-networks.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= protected-networks.net; h=content-type:content-type:subject :subject:from:from:content-language:user-agent:mime-version:date :date:message-id; s=201508; t=1633634924; bh=2aPJcxtVvrZo6dYuYlL a790lNWqYlw4Mj4ckUAsxXNk=; b=QFErgMbI12vArV5I3aOcWRn8KfQeVPK8YL5 nifuYPIakDi2pffSQY7VxcK6OhMdUn7E2u4m3KvFzjdop8OSOVIhoPUefUSU1K9B bx5oOSflMy8cf7gZ8WN7d5aL/YCgQHBlYsHN0Y5yXitiN72IXSazsja0DVL+NcCh Umux5qlo= Received: from [192.168.1.10] (toshi.auburn.protected-networks.net [192.168.1.10]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: imb@mail.protected-networks.net) by mail.protected-networks.net (Postfix) with ESMTPSA id 9D7F91AF60 for ; Thu, 7 Oct 2021 15:28:44 -0400 (EDT) Message-ID: <2908d747-8606-84d6-60b5-249c0d396b6b@protected-networks.net> Date: Thu, 7 Oct 2021 15:28:44 -0400 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Content-Language: en-NZ To: freebsd-current Subject: intermittent bsdtar/jemalloc failures Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------VUj5LsiWESS3lw1MlffNxk0w" X-Rspamd-Queue-Id: 4HQLwP3MkZz4jSK X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=protected-networks.net header.s=201508 header.b=QFErgMbI; dmarc=pass (policy=reject) header.from=protected-networks.net; spf=pass (mx1.freebsd.org: domain of imb@protected-networks.net designates 202.12.127.228 as permitted sender) smtp.mailfrom=imb@protected-networks.net X-Spamd-Result: default: False [-5.00 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[protected-networks.net:s=201508]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; HAS_ATTACHMENT(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; MIME_BASE64_TEXT_BOGUS(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[protected-networks.net:+]; MIME_BASE64_TEXT(0.10)[]; DMARC_POLICY_ALLOW(-0.50)[protected-networks.net,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~]; ASN(0.00)[asn:5716, ipnet:202.12.127.0/24, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] Reply-To: imb@protected-networks.net From: Michael Butler via freebsd-current X-Original-From: Michael Butler X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------VUj5LsiWESS3lw1MlffNxk0w Content-Type: multipart/mixed; boundary="------------ttlLT5Tz75Iy8DDsYpKNwh0A"; protected-headers="v1" From: Michael Butler To: freebsd-current Message-ID: <2908d747-8606-84d6-60b5-249c0d396b6b@protected-networks.net> Subject: intermittent bsdtar/jemalloc failures --------------ttlLT5Tz75Iy8DDsYpKNwh0A Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 V2hpbGUgYnVpbGRpbmcgYSBsb2NhbCByZWxlYXNlIGJ1bmRsZSwgSSBzb21ldGltZXMgZ2V0 IGJzZHRhciBmYWlsaW5nIA0KKGFuZCBkdW1waW5nIGNvcmUpIGFzIGZvbGxvd3MgYmVsb3cu IFdvcnNlLCBhcyBjYW4gYmUgc2VlbiBiZWxvdywgaXQgDQpkb2Vzbid0IHN0b3AgdGhlIGJ1 aWxkIHVubGVzcyBJIGhhcHBlbiB0byBub3RpY2UgYW5kIGl0IHlpZWxkcyBhbiANCmluY29t cGxldGUgcGFja2FnZS4NCg0KYSB1c3Ivc3JjL3N5cy9uZXRncmFwaC9uZ19jaGVja3N1bS5o DQphIHVzci9zcmMvc3lzL25ldGdyYXBoL25nX21lc3NhZ2UuaA0KYSB1c3Ivc3JjL3N5cy9u ZXRncmFwaC9uZ19lY2hvLmMNCmEgdXNyL3NyYy9zeXMvbmV0Z3JhcGgvbmdfZ2lmLmgNCjxq ZW1hbGxvYz46IGplbWFsbG9jX2FyZW5hLmM6NzQ3OiBGYWlsZWQgYXNzZXJ0aW9uOiANCiJu c3RpbWVfY29tcGFyZSgmZGVjYXktPmVwb2NoLCAmdGltZSkgPD0gMCINCkFib3J0IHRyYXAg KGNvcmUgZHVtcGVkKQ0Kc2ggL3Vzci9zcmMvcmVsZWFzZS9zY3JpcHRzL21ha2UtbWFuaWZl c3Quc2ggKi50eHogPiBNQU5JRkVTVA0KDQpXaGF0IGNhdXNlcyB0aGlzPyBCdWlsZCBtYWNo aW5lIGlzIGEgMng0LWNvcmUgSW50ZWwgYm94IHdpdGggWkZTIA0KZmlsZS1zeXN0ZW1zIGFs bCBhcm91bmQuIEkgdHJpZWQgc3RvcHBpbmcgTlRQRCB0ZW1wb3JhcmlseSBidXQgdGhlIA0K ZmFpbHVyZXMgcGVyc2lzdCAuLiBzb21ldGltZXMgOi0oDQoNCkkndmUgc2VlbiB0aGlzIGF0 IGRpZmZlcmVudCBwb2ludHMgaW4gdGhlIGFyY2hpdmluZyBwcm9jZXNzIHNvIGl0IA0KZG9l c24ndCBzZWVtIHNwZWNpZmljIHRvIGJ1aWxkaW5nIGtlcm5lbC50eHouDQoNCkFueSB0aG91 Z2h0cz8NCg0KCWltYg0K --------------ttlLT5Tz75Iy8DDsYpKNwh0A-- --------------VUj5LsiWESS3lw1MlffNxk0w Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wmMEABEIACMWIQRvY+Y5ncyOPpTWDwZC/2uuBELUkgUCYV9KbAUDAAAAAAAKCRBC/2uuBELUkuAc AJ0ZcoE7qa6FysOsOqKGT9Q+8L4rkwCfT4RzfzrX9T9TFErbAO/pvurcoaI= =vpXR -----END PGP SIGNATURE----- --------------VUj5LsiWESS3lw1MlffNxk0w-- From nobody Thu Oct 7 19:39:48 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E5A0217E50E5 for ; Thu, 7 Oct 2021 19:39:55 +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 4HQM9742YLz4ldR for ; Thu, 7 Oct 2021 19:39:55 +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 197JdmC5087059 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Thu, 7 Oct 2021 22:39:51 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 197JdmC5087059 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 197Jdmqv087058; Thu, 7 Oct 2021 22:39:48 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Thu, 7 Oct 2021 22:39:48 +0300 From: Konstantin Belousov To: imb@protected-networks.net Cc: freebsd-current Subject: Re: intermittent bsdtar/jemalloc failures Message-ID: References: <2908d747-8606-84d6-60b5-249c0d396b6b@protected-networks.net> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2908d747-8606-84d6-60b5-249c0d396b6b@protected-networks.net> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on tom.home X-Rspamd-Queue-Id: 4HQM9742YLz4ldR X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Thu, Oct 07, 2021 at 03:28:44PM -0400, Michael Butler via freebsd-current wrote: > While building a local release bundle, I sometimes get bsdtar failing (and > dumping core) as follows below. Worse, as can be seen below, it doesn't stop > the build unless I happen to notice and it yields an incomplete package. > > a usr/src/sys/netgraph/ng_checksum.h > a usr/src/sys/netgraph/ng_message.h > a usr/src/sys/netgraph/ng_echo.c > a usr/src/sys/netgraph/ng_gif.h > : jemalloc_arena.c:747: Failed assertion: > "nstime_compare(&decay->epoch, &time) <= 0" > Abort trap (core dumped) > sh /usr/src/release/scripts/make-manifest.sh *.txz > MANIFEST > > What causes this? Build machine is a 2x4-core Intel box with ZFS > file-systems all around. I tried stopping NTPD temporarily but the failures > persist .. sometimes :-( > > I've seen this at different points in the archiving process so it doesn't > seem specific to building kernel.txz. What timecounter do you use? Perhaps show the whole output from sysctl kern.timecounter. From nobody Thu Oct 7 20:18:28 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4D6F717ED6DD for ; Thu, 7 Oct 2021 20:18:31 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.protected-networks.net (mail.protected-networks.net [IPv6:2001:470:8d59:1::8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.protected-networks.net", Issuer "R3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HQN1g0hjlz4vZH for ; Thu, 7 Oct 2021 20:18:31 +0000 (UTC) (envelope-from imb@protected-networks.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= protected-networks.net; h=content-type:content-type:in-reply-to :from:from:references:content-language:subject:subject :user-agent:mime-version:date:date:message-id; s=201508; t= 1633637909; bh=iDwAIOwpknGsP80uUG4sxkjC+xPWsXZsjlS/ckTiZLI=; b=H wbajAAM6gbYzQX26vcTxlnzDNGiTDDWfv8WvpEGAY3PkPn6dqzeNTfqnb82cSFey PcbnqW6THziYvX0CuZxwDsTxaxi4CVPoiaIDxfMMct2RYWKF1bw5jbZupCb0Tny8 nY+hhsZYisMsJvMZcebyugv0Hm0TfHi965AGQ1VKJg= Received: from [192.168.1.10] (toshi.auburn.protected-networks.net [192.168.1.10]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (Client did not present a certificate) (Authenticated sender: imb@mail.protected-networks.net) by mail.protected-networks.net (Postfix) with ESMTPSA id 006142809E; Thu, 7 Oct 2021 16:18:28 -0400 (EDT) Message-ID: <31be6e3a-f303-ce78-4dab-5dcc77ed0464@protected-networks.net> Date: Thu, 7 Oct 2021 16:18:28 -0400 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Subject: Re: intermittent bsdtar/jemalloc failures Content-Language: en-NZ To: Konstantin Belousov Cc: freebsd-current References: <2908d747-8606-84d6-60b5-249c0d396b6b@protected-networks.net> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------C27Bnea3j031l1tPzQ0of1D1" X-Rspamd-Queue-Id: 4HQN1g0hjlz4vZH X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: imb@protected-networks.net From: Michael Butler via freebsd-current X-Original-From: Michael Butler X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------C27Bnea3j031l1tPzQ0of1D1 Content-Type: multipart/mixed; boundary="------------ecwZPNjRkdy75fHYAIxcSlrq"; protected-headers="v1" From: Michael Butler To: Konstantin Belousov Cc: freebsd-current Message-ID: <31be6e3a-f303-ce78-4dab-5dcc77ed0464@protected-networks.net> Subject: Re: intermittent bsdtar/jemalloc failures References: <2908d747-8606-84d6-60b5-249c0d396b6b@protected-networks.net> In-Reply-To: --------------ecwZPNjRkdy75fHYAIxcSlrq Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMTAvNy8yMSAxNTozOSwgS29uc3RhbnRpbiBCZWxvdXNvdiB3cm90ZToNCj4gT24gVGh1 LCBPY3QgMDcsIDIwMjEgYXQgMDM6Mjg6NDRQTSAtMDQwMCwgTWljaGFlbCBCdXRsZXIgdmlh IGZyZWVic2QtY3VycmVudCB3cm90ZToNCj4+IFdoaWxlIGJ1aWxkaW5nIGEgbG9jYWwgcmVs ZWFzZSBidW5kbGUsIEkgc29tZXRpbWVzIGdldCBic2R0YXIgZmFpbGluZyAoYW5kDQo+PiBk dW1waW5nIGNvcmUpIGFzIGZvbGxvd3MgYmVsb3cuIFdvcnNlLCBhcyBjYW4gYmUgc2VlbiBi ZWxvdywgaXQgZG9lc24ndCBzdG9wDQo+PiB0aGUgYnVpbGQgdW5sZXNzIEkgaGFwcGVuIHRv IG5vdGljZSBhbmQgaXQgeWllbGRzIGFuIGluY29tcGxldGUgcGFja2FnZS4NCj4+DQo+PiBh IHVzci9zcmMvc3lzL25ldGdyYXBoL25nX2NoZWNrc3VtLmgNCj4+IGEgdXNyL3NyYy9zeXMv bmV0Z3JhcGgvbmdfbWVzc2FnZS5oDQo+PiBhIHVzci9zcmMvc3lzL25ldGdyYXBoL25nX2Vj aG8uYw0KPj4gYSB1c3Ivc3JjL3N5cy9uZXRncmFwaC9uZ19naWYuaA0KPj4gPGplbWFsbG9j PjogamVtYWxsb2NfYXJlbmEuYzo3NDc6IEZhaWxlZCBhc3NlcnRpb246DQo+PiAibnN0aW1l X2NvbXBhcmUoJmRlY2F5LT5lcG9jaCwgJnRpbWUpIDw9IDAiDQo+PiBBYm9ydCB0cmFwIChj b3JlIGR1bXBlZCkNCj4+IHNoIC91c3Ivc3JjL3JlbGVhc2Uvc2NyaXB0cy9tYWtlLW1hbmlm ZXN0LnNoICoudHh6ID4gTUFOSUZFU1QNCj4+DQo+PiBXaGF0IGNhdXNlcyB0aGlzPyBCdWls ZCBtYWNoaW5lIGlzIGEgMng0LWNvcmUgSW50ZWwgYm94IHdpdGggWkZTDQo+PiBmaWxlLXN5 c3RlbXMgYWxsIGFyb3VuZC4gSSB0cmllZCBzdG9wcGluZyBOVFBEIHRlbXBvcmFyaWx5IGJ1 dCB0aGUgZmFpbHVyZXMNCj4+IHBlcnNpc3QgLi4gc29tZXRpbWVzIDotKA0KPj4NCj4+IEkn dmUgc2VlbiB0aGlzIGF0IGRpZmZlcmVudCBwb2ludHMgaW4gdGhlIGFyY2hpdmluZyBwcm9j ZXNzIHNvIGl0IGRvZXNuJ3QNCj4+IHNlZW0gc3BlY2lmaWMgdG8gYnVpbGRpbmcga2VybmVs LnR4ei4NCj4gDQo+IFdoYXQgdGltZWNvdW50ZXIgZG8geW91IHVzZT8gUGVyaGFwcyBzaG93 IHRoZSB3aG9sZSBvdXRwdXQgZnJvbQ0KPiBzeXNjdGwga2Vybi50aW1lY291bnRlci4NCg0K aW1iQHZtMDE6L2hvbWUvaW1iPiBzeXNjdGwga2Vybi50aW1lY291bnRlcg0Ka2Vybi50aW1l Y291bnRlci50c2Nfc2hpZnQ6IDENCmtlcm4udGltZWNvdW50ZXIuc21wX3RzY19hZGp1c3Q6 IDANCmtlcm4udGltZWNvdW50ZXIuc21wX3RzYzogMQ0Ka2Vybi50aW1lY291bnRlci5pbnZh cmlhbnRfdHNjOiAxDQprZXJuLnRpbWVjb3VudGVyLmZhc3RfZ2V0dGltZTogMQ0Ka2Vybi50 aW1lY291bnRlci50aWNrOiAxDQprZXJuLnRpbWVjb3VudGVyLmNob2ljZTogQUNQSS1mYXN0 KDkwMCkgSFBFVCg5NTApIGk4MjU0KDApIFRTQy1sb3coMTAwMCkgDQpkdW1teSgtMTAwMDAw MCkNCmtlcm4udGltZWNvdW50ZXIuaGFyZHdhcmU6IEhQRVQNCmtlcm4udGltZWNvdW50ZXIu YWxsb3dlZGRldmlhdGlvbjogNQ0Ka2Vybi50aW1lY291bnRlci50aW1laGFuZHNfY291bnQ6 IDINCmtlcm4udGltZWNvdW50ZXIuc3RlcHdhcm5pbmdzOiAwDQprZXJuLnRpbWVjb3VudGVy LnRjLkFDUEktZmFzdC5xdWFsaXR5OiA5MDANCmtlcm4udGltZWNvdW50ZXIudGMuQUNQSS1m YXN0LmZyZXF1ZW5jeTogMzU3OTU0NQ0Ka2Vybi50aW1lY291bnRlci50Yy5BQ1BJLWZhc3Qu Y291bnRlcjogMTYxMjQ4OTINCmtlcm4udGltZWNvdW50ZXIudGMuQUNQSS1mYXN0Lm1hc2s6 IDE2Nzc3MjE1DQprZXJuLnRpbWVjb3VudGVyLnRjLkhQRVQucXVhbGl0eTogOTUwDQprZXJu LnRpbWVjb3VudGVyLnRjLkhQRVQuZnJlcXVlbmN5OiAxNDMxODE4MA0Ka2Vybi50aW1lY291 bnRlci50Yy5IUEVULmNvdW50ZXI6IDE4ODM5OTUyMjkNCmtlcm4udGltZWNvdW50ZXIudGMu SFBFVC5tYXNrOiA0Mjk0OTY3Mjk1DQprZXJuLnRpbWVjb3VudGVyLnRjLmk4MjU0LnF1YWxp dHk6IDANCmtlcm4udGltZWNvdW50ZXIudGMuaTgyNTQuZnJlcXVlbmN5OiAxMTkzMTgyDQpr ZXJuLnRpbWVjb3VudGVyLnRjLmk4MjU0LmNvdW50ZXI6IDU3DQprZXJuLnRpbWVjb3VudGVy LnRjLmk4MjU0Lm1hc2s6IDY1NTM1DQprZXJuLnRpbWVjb3VudGVyLnRjLlRTQy1sb3cucXVh bGl0eTogMTAwMA0Ka2Vybi50aW1lY291bnRlci50Yy5UU0MtbG93LmZyZXF1ZW5jeTogMTQx MzE1MzAwNw0Ka2Vybi50aW1lY291bnRlci50Yy5UU0MtbG93LmNvdW50ZXI6IDIzNTIwMDIy OTUNCmtlcm4udGltZWNvdW50ZXIudGMuVFNDLWxvdy5tYXNrOiA0Mjk0OTY3Mjk1DQoNCkkg b3ZlcnJvZGUgdGhlIGRlZmF1bHQgc2VsZWN0aW9uIG9mIGNvdW50ZXItdHlwZSBhcyBOVFBE IGRyaWZ0ZWQgc28gDQpiYWRseSBhcyB0byByZXF1aXJlIHN0ZXBwaW5nIGFsbW9zdCBob3Vy bHkgOi0oDQoNClNvIC4uIEkgaGF2ZSB0aGlzIGluIC9ldGMvc3lzY3RsLmNvbmYgLi4NCg0K a2Vybi50aW1lY291bnRlci5oYXJkd2FyZT1IUEVUDQoNCldoaWxlIEkgaG9wZSBpdCB3b3Vs ZG4ndCBtYWtlIGEgZGlmZmVyZW5jZSwgSSBhbHNvIGhhdmUgcG93ZXJkIGVuYWJsZWQgDQpp biAvZXRjL3JjLmNvbmYgdG8gKG1hcmdpbmFsbHkpIHJlZHVjZSB0aGUgcG93ZXItY29uc3Vt cHRpb24gd2hlbiB0aGUgDQptYWNoaW5lIGlzIG5lYXItaWRsZS4gc3lzY3RsIC1hIHwgZ3Jl cCBeZGV2LmNwdSB8IGdyZXAgZnJlcSBzaG93cyAuLg0KDQpkZXYuY3B1LjcuZnJlcV9sZXZl bHM6IDI4MzQvMTAzMDAwIDIzMzMvOTAwMDAgMjAwMC83OTAwMA0KZGV2LmNwdS43LmZyZXE6 IDI4MzQNCmRldi5jcHUuMy5mcmVxX2xldmVsczogMjgzNC8xMDMwMDAgMjMzMy85NDAwMCAy MDAwLzg2MDAwDQpkZXYuY3B1LjMuZnJlcTogMjgzNA0KZGV2LmNwdS41LmZyZXFfbGV2ZWxz OiAyODM0LzEwMzAwMCAyMzMzLzkwMDAwIDIwMDAvNzkwMDANCmRldi5jcHUuNS5mcmVxOiAy ODM0DQpkZXYuY3B1LjEuZnJlcV9sZXZlbHM6IDI4MzQvMTAzMDAwIDIzMzMvOTQwMDAgMjAw MC84NjAwMA0KZGV2LmNwdS4xLmZyZXE6IDI4MzQNCmRldi5jcHUuNi5mcmVxX2xldmVsczog MjgzNC8xMDMwMDAgMjMzMy85MDAwMCAyMDAwLzc5MDAwDQpkZXYuY3B1LjYuZnJlcTogMjgz NA0KZGV2LmNwdS4yLmZyZXFfbGV2ZWxzOiAyODM0LzEwMzAwMCAyMzMzLzk0MDAwIDIwMDAv ODYwMDANCmRldi5jcHUuMi5mcmVxOiAyODM0DQpkZXYuY3B1LjQuZnJlcV9sZXZlbHM6IDI4 MzQvMTAzMDAwIDIzMzMvOTAwMDAgMjAwMC83OTAwMA0KZGV2LmNwdS40LmZyZXE6IDI4MzQN CmRldi5jcHUuMC5mcmVxX2xldmVsczogMjgzNC8xMDMwMDAgMjMzMy85NDAwMCAyMDAwLzg2 MDAwDQpkZXYuY3B1LjAuZnJlcTogMjgzNA0KDQoJaW1iDQo= --------------ecwZPNjRkdy75fHYAIxcSlrq-- --------------C27Bnea3j031l1tPzQ0of1D1 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wmMEABEIACMWIQRvY+Y5ncyOPpTWDwZC/2uuBELUkgUCYV9WFAUDAAAAAAAKCRBC/2uuBELUkgaZ AJ4uyl+QLOdf2keIr9CUu6938zW0gQCgmrz1OLfc/M2MtNW9tNpzEEgNsvw= =Q2s+ -----END PGP SIGNATURE----- --------------C27Bnea3j031l1tPzQ0of1D1-- From nobody Thu Oct 7 20:52:52 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 712BA12B9B6C for ; Thu, 7 Oct 2021 20:52:56 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HQNnN2bqCz50NK for ; Thu, 7 Oct 2021 20:52:56 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qt1-x830.google.com with SMTP id r1so7545503qta.12 for ; Thu, 07 Oct 2021 13:52:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=vplskjgBLCQoZyRkA36+u3+1mPEKrOdD8xEg/QgA9tE=; b=lTZtUpxdg01spiK1nQJUqynJWR+rJQBrPfMxXy7eemlf9H3B/XgG7Y/89Ci2zTXFV8 iLdTptYCCoNL9gO2HIBPlK3c71zKAiT5WYUTIiU4krYQhlnCY4+zpL0Tp4WLTe149EWu ueUADFTCoSWxRJ8/El7mJXenzMCpKQHK7g0H9w2XC5rlv7MInXhWnKcyHjgh9vmGDpXO vclpzyZvIQxeB+69s9/EUalCGyOEfVs4AuQK3/6wqnwtYF74c+qA3ooVthSnXLvOOwvO O+YKdm2myOauNlxCv0qDL5Gfh6XneQEWGpNj275avI6qiaTXAacgzMJ9SXzDv3QvG1WS vQFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=vplskjgBLCQoZyRkA36+u3+1mPEKrOdD8xEg/QgA9tE=; b=RG8v6PUyfxRG9ZjDzf++uGzNghyjII99r5x8ZFkYp2KvbPRIDS77AR+h0XpTCNfSZh oSPcb1qrcuzkTVgMxjRHxCmk0YRZNlxhCecDRZVTpyWcGkK51MedE8kWgOhjHFe7e6k3 eKNBZ66YaFvN5F0y6eh+RzDtu6uvNQrp1M2Pi4+KS3wgnRoqlejDGCuxnelVywvEtaPN F6wMHTLdeaaYWgF3UlpHhs/0KJnRBvHaeIPNv5le+GgmSXuQg0WRe7ktgGGX+BxCgj/F rM1uLMnFW4/ujvQzfxGMzbI/qRlTOzXkWC4/kXepBpdbMgN+PmFldtAOA5/Wk/zi1XsM 4DyA== X-Gm-Message-State: AOAM530cIl+QwkABa4raU6LS17yY9Zddjb3prK6q8oEmTR5LCteSlIdU dy3IhsoMR63K5cf3VXpxQ4ZI7gGeFaE= X-Google-Smtp-Source: ABdhPJxvwcIh+pWblzCrDfDwzE0JzbX86pJyXs20bB6zP+dF+a35K0TfGLLaJlmJhcGxBe/FyAJgMA== X-Received: by 2002:ac8:4084:: with SMTP id p4mr7569934qtl.306.1633639970487; Thu, 07 Oct 2021 13:52:50 -0700 (PDT) Received: from nuc ([142.126.186.191]) by smtp.gmail.com with ESMTPSA id c8sm529888qtb.9.2021.10.07.13.52.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Oct 2021 13:52:50 -0700 (PDT) Date: Thu, 7 Oct 2021 16:52:52 -0400 From: Mark Johnston To: imb@protected-networks.net Cc: Konstantin Belousov , freebsd-current Subject: Re: intermittent bsdtar/jemalloc failures Message-ID: References: <2908d747-8606-84d6-60b5-249c0d396b6b@protected-networks.net> <31be6e3a-f303-ce78-4dab-5dcc77ed0464@protected-networks.net> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <31be6e3a-f303-ce78-4dab-5dcc77ed0464@protected-networks.net> X-Rspamd-Queue-Id: 4HQNnN2bqCz50NK X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Thu, Oct 07, 2021 at 04:18:28PM -0400, Michael Butler via freebsd-current wrote: > On 10/7/21 15:39, Konstantin Belousov wrote: > > On Thu, Oct 07, 2021 at 03:28:44PM -0400, Michael Butler via freebsd-current wrote: > >> While building a local release bundle, I sometimes get bsdtar failing (and > >> dumping core) as follows below. Worse, as can be seen below, it doesn't stop > >> the build unless I happen to notice and it yields an incomplete package. > >> > >> a usr/src/sys/netgraph/ng_checksum.h > >> a usr/src/sys/netgraph/ng_message.h > >> a usr/src/sys/netgraph/ng_echo.c > >> a usr/src/sys/netgraph/ng_gif.h > >> : jemalloc_arena.c:747: Failed assertion: > >> "nstime_compare(&decay->epoch, &time) <= 0" > >> Abort trap (core dumped) > >> sh /usr/src/release/scripts/make-manifest.sh *.txz > MANIFEST > >> > >> What causes this? Build machine is a 2x4-core Intel box with ZFS > >> file-systems all around. I tried stopping NTPD temporarily but the failures > >> persist .. sometimes :-( > >> > >> I've seen this at different points in the archiving process so it doesn't > >> seem specific to building kernel.txz. > > > > What timecounter do you use? Perhaps show the whole output from > > sysctl kern.timecounter. > > imb@vm01:/home/imb> sysctl kern.timecounter > kern.timecounter.tsc_shift: 1 > kern.timecounter.smp_tsc_adjust: 0 > kern.timecounter.smp_tsc: 1 > kern.timecounter.invariant_tsc: 1 > kern.timecounter.fast_gettime: 1 > kern.timecounter.tick: 1 > kern.timecounter.choice: ACPI-fast(900) HPET(950) i8254(0) TSC-low(1000) > dummy(-1000000) > kern.timecounter.hardware: HPET > kern.timecounter.alloweddeviation: 5 > kern.timecounter.timehands_count: 2 > kern.timecounter.stepwarnings: 0 > kern.timecounter.tc.ACPI-fast.quality: 900 > kern.timecounter.tc.ACPI-fast.frequency: 3579545 > kern.timecounter.tc.ACPI-fast.counter: 16124892 > kern.timecounter.tc.ACPI-fast.mask: 16777215 > kern.timecounter.tc.HPET.quality: 950 > kern.timecounter.tc.HPET.frequency: 14318180 > kern.timecounter.tc.HPET.counter: 1883995229 > kern.timecounter.tc.HPET.mask: 4294967295 > kern.timecounter.tc.i8254.quality: 0 > kern.timecounter.tc.i8254.frequency: 1193182 > kern.timecounter.tc.i8254.counter: 57 > kern.timecounter.tc.i8254.mask: 65535 > kern.timecounter.tc.TSC-low.quality: 1000 > kern.timecounter.tc.TSC-low.frequency: 1413153007 > kern.timecounter.tc.TSC-low.counter: 2352002295 > kern.timecounter.tc.TSC-low.mask: 4294967295 > > I overrode the default selection of counter-type as NTPD drifted so > badly as to require stepping almost hourly :-( Could you show output from # kldload cpuctl # cpucontrol -i 0x15 /dev/cpuctl0 # cpucontrol -i 0x16 /dev/cpuctl0 as well as a copy of the dmesg after a boot? I am looking at a similar problem currently. From nobody Thu Oct 7 21:11:45 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B59B712BC8A9 for ; Thu, 7 Oct 2021 21:11:53 +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 4HQPCF1TM6z52km; Thu, 7 Oct 2021 21:11:53 +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 197LBjiW010545 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 8 Oct 2021 00:11:48 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 197LBjiW010545 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 197LBj3h010544; Fri, 8 Oct 2021 00:11:45 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 8 Oct 2021 00:11:45 +0300 From: Konstantin Belousov To: Mark Johnston Cc: imb@protected-networks.net, freebsd-current Subject: Re: intermittent bsdtar/jemalloc failures Message-ID: References: <2908d747-8606-84d6-60b5-249c0d396b6b@protected-networks.net> <31be6e3a-f303-ce78-4dab-5dcc77ed0464@protected-networks.net> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on tom.home X-Rspamd-Queue-Id: 4HQPCF1TM6z52km X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Thu, Oct 07, 2021 at 04:52:52PM -0400, Mark Johnston wrote: > On Thu, Oct 07, 2021 at 04:18:28PM -0400, Michael Butler via freebsd-current wrote: > > On 10/7/21 15:39, Konstantin Belousov wrote: > > > On Thu, Oct 07, 2021 at 03:28:44PM -0400, Michael Butler via freebsd-current wrote: > > >> While building a local release bundle, I sometimes get bsdtar failing (and > > >> dumping core) as follows below. Worse, as can be seen below, it doesn't stop > > >> the build unless I happen to notice and it yields an incomplete package. > > >> > > >> a usr/src/sys/netgraph/ng_checksum.h > > >> a usr/src/sys/netgraph/ng_message.h > > >> a usr/src/sys/netgraph/ng_echo.c > > >> a usr/src/sys/netgraph/ng_gif.h > > >> : jemalloc_arena.c:747: Failed assertion: > > >> "nstime_compare(&decay->epoch, &time) <= 0" > > >> Abort trap (core dumped) > > >> sh /usr/src/release/scripts/make-manifest.sh *.txz > MANIFEST > > >> > > >> What causes this? Build machine is a 2x4-core Intel box with ZFS > > >> file-systems all around. I tried stopping NTPD temporarily but the failures > > >> persist .. sometimes :-( > > >> > > >> I've seen this at different points in the archiving process so it doesn't > > >> seem specific to building kernel.txz. > > > > > > What timecounter do you use? Perhaps show the whole output from > > > sysctl kern.timecounter. > > > > imb@vm01:/home/imb> sysctl kern.timecounter > > kern.timecounter.tsc_shift: 1 > > kern.timecounter.smp_tsc_adjust: 0 > > kern.timecounter.smp_tsc: 1 > > kern.timecounter.invariant_tsc: 1 > > kern.timecounter.fast_gettime: 1 > > kern.timecounter.tick: 1 > > kern.timecounter.choice: ACPI-fast(900) HPET(950) i8254(0) TSC-low(1000) > > dummy(-1000000) > > kern.timecounter.hardware: HPET > > kern.timecounter.alloweddeviation: 5 > > kern.timecounter.timehands_count: 2 > > kern.timecounter.stepwarnings: 0 > > kern.timecounter.tc.ACPI-fast.quality: 900 > > kern.timecounter.tc.ACPI-fast.frequency: 3579545 > > kern.timecounter.tc.ACPI-fast.counter: 16124892 > > kern.timecounter.tc.ACPI-fast.mask: 16777215 > > kern.timecounter.tc.HPET.quality: 950 > > kern.timecounter.tc.HPET.frequency: 14318180 > > kern.timecounter.tc.HPET.counter: 1883995229 > > kern.timecounter.tc.HPET.mask: 4294967295 > > kern.timecounter.tc.i8254.quality: 0 > > kern.timecounter.tc.i8254.frequency: 1193182 > > kern.timecounter.tc.i8254.counter: 57 > > kern.timecounter.tc.i8254.mask: 65535 > > kern.timecounter.tc.TSC-low.quality: 1000 > > kern.timecounter.tc.TSC-low.frequency: 1413153007 > > kern.timecounter.tc.TSC-low.counter: 2352002295 > > kern.timecounter.tc.TSC-low.mask: 4294967295 > > > > I overrode the default selection of counter-type as NTPD drifted so > > badly as to require stepping almost hourly :-( > > Could you show output from > > # kldload cpuctl > # cpucontrol -i 0x15 /dev/cpuctl0 > # cpucontrol -i 0x16 /dev/cpuctl0 > > as well as a copy of the dmesg after a boot? I am looking at a similar > problem currently. Do you have the issue with jemalloc(3), or the problem with imprecise TSC frequency as reported by CPUID leaf? From nobody Thu Oct 7 21:14:48 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 339A312BD2EC for ; Thu, 7 Oct 2021 21:15:07 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-lf1-f52.google.com (mail-lf1-f52.google.com [209.85.167.52]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HQPGz0pG9z53rk; Thu, 7 Oct 2021 21:15:07 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-lf1-f52.google.com with SMTP id x27so30476562lfu.5; Thu, 07 Oct 2021 14:15:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=801Lpop6JQJpdIQnn2AfvSvNyfNLM7W4tnz15tP2K+A=; b=Wns5/TmWMYGVVJ3/AqTfonf5AiymFlEZmFYim8+aseDgxF6DAbiL4+km9Gzez6SNoS QD+jn3HWumuNDkQ1bVcSY1h0fg3bqJHNyQmp4yIO+BTowZNbrBlAlKaX2g7nIoHb8vf1 6lkAU+4yth36P4MrzENAmvB9U4FmGO76mr0a9RAwoPdrFlveO3EHZfAdWBa5kmcZpAcb Ywk/nLDoQYoqkAax7NABMBaX6qYo2nAhaz+IGWhQKJHPq+b0Hs7O09Re3nS3yOVVQ9QA xAfrJC6v0x6N8nPtc1GC6tAjdsXK1s1mKNdVXxqm6Ez0WLldIH4vTAyUnkfcBIA1P0/1 3h1A== X-Gm-Message-State: AOAM530jvte3GkcHsUDOrQbbQlxCtMYNv0CS8lttq02/Wos21BBfLT9u brBXtb+GtKz0VtLcUZfzXf1Er4KaN1wJAjKRtBc= X-Google-Smtp-Source: ABdhPJx5tVLvBsN67yyBLifIK0qcVaZI86w6t9OeEjcbtv341jBUQSnsAtsmIWfweuaTQkXKECQHq1fZO6aGYCzvYyM= X-Received: by 2002:a2e:3c04:: with SMTP id j4mr7237005lja.271.1633641299776; Thu, 07 Oct 2021 14:14:59 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <2908d747-8606-84d6-60b5-249c0d396b6b@protected-networks.net> <31be6e3a-f303-ce78-4dab-5dcc77ed0464@protected-networks.net> In-Reply-To: From: Mark Johnston Date: Thu, 7 Oct 2021 17:14:48 -0400 Message-ID: Subject: Re: intermittent bsdtar/jemalloc failures To: Konstantin Belousov Cc: Mark Johnston , Michael Butler , freebsd-current Content-Type: multipart/alternative; boundary="0000000000005d179005cdc9c195" X-Rspamd-Queue-Id: 4HQPGz0pG9z53rk X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --0000000000005d179005cdc9c195 Content-Type: text/plain; charset="UTF-8" On Thu., Oct. 7, 2021, 17:11 Konstantin Belousov, wrote: > On Thu, Oct 07, 2021 at 04:52:52PM -0400, Mark Johnston wrote: > > On Thu, Oct 07, 2021 at 04:18:28PM -0400, Michael Butler via > freebsd-current wrote: > > > On 10/7/21 15:39, Konstantin Belousov wrote: > > > > On Thu, Oct 07, 2021 at 03:28:44PM -0400, Michael Butler via > freebsd-current wrote: > > > >> While building a local release bundle, I sometimes get bsdtar > failing (and > > > >> dumping core) as follows below. Worse, as can be seen below, it > doesn't stop > > > >> the build unless I happen to notice and it yields an incomplete > package. > > > >> > > > >> a usr/src/sys/netgraph/ng_checksum.h > > > >> a usr/src/sys/netgraph/ng_message.h > > > >> a usr/src/sys/netgraph/ng_echo.c > > > >> a usr/src/sys/netgraph/ng_gif.h > > > >> : jemalloc_arena.c:747: Failed assertion: > > > >> "nstime_compare(&decay->epoch, &time) <= 0" > > > >> Abort trap (core dumped) > > > >> sh /usr/src/release/scripts/make-manifest.sh *.txz > MANIFEST > > > >> > > > >> What causes this? Build machine is a 2x4-core Intel box with ZFS > > > >> file-systems all around. I tried stopping NTPD temporarily but the > failures > > > >> persist .. sometimes :-( > > > >> > > > >> I've seen this at different points in the archiving process so it > doesn't > > > >> seem specific to building kernel.txz. > > > > > > > > What timecounter do you use? Perhaps show the whole output from > > > > sysctl kern.timecounter. > > > > > > imb@vm01:/home/imb> sysctl kern.timecounter > > > kern.timecounter.tsc_shift: 1 > > > kern.timecounter.smp_tsc_adjust: 0 > > > kern.timecounter.smp_tsc: 1 > > > kern.timecounter.invariant_tsc: 1 > > > kern.timecounter.fast_gettime: 1 > > > kern.timecounter.tick: 1 > > > kern.timecounter.choice: ACPI-fast(900) HPET(950) i8254(0) > TSC-low(1000) > > > dummy(-1000000) > > > kern.timecounter.hardware: HPET > > > kern.timecounter.alloweddeviation: 5 > > > kern.timecounter.timehands_count: 2 > > > kern.timecounter.stepwarnings: 0 > > > kern.timecounter.tc.ACPI-fast.quality: 900 > > > kern.timecounter.tc.ACPI-fast.frequency: 3579545 > > > kern.timecounter.tc.ACPI-fast.counter: 16124892 > > > kern.timecounter.tc.ACPI-fast.mask: 16777215 > > > kern.timecounter.tc.HPET.quality: 950 > > > kern.timecounter.tc.HPET.frequency: 14318180 > > > kern.timecounter.tc.HPET.counter: 1883995229 > > > kern.timecounter.tc.HPET.mask: 4294967295 > > > kern.timecounter.tc.i8254.quality: 0 > > > kern.timecounter.tc.i8254.frequency: 1193182 > > > kern.timecounter.tc.i8254.counter: 57 > > > kern.timecounter.tc.i8254.mask: 65535 > > > kern.timecounter.tc.TSC-low.quality: 1000 > > > kern.timecounter.tc.TSC-low.frequency: 1413153007 > > > kern.timecounter.tc.TSC-low.counter: 2352002295 > > > kern.timecounter.tc.TSC-low.mask: 4294967295 > > > > > > I overrode the default selection of counter-type as NTPD drifted so > > > badly as to require stepping almost hourly :-( > > > > Could you show output from > > > > # kldload cpuctl > > # cpucontrol -i 0x15 /dev/cpuctl0 > > # cpucontrol -i 0x16 /dev/cpuctl0 > > > > as well as a copy of the dmesg after a boot? I am looking at a similar > > problem currently. > > Do you have the issue with jemalloc(3), or the problem with imprecise TSC > frequency as reported by CPUID leaf? > Only the latter, but I did not try overriding the time counter selection. > --0000000000005d179005cdc9c195-- From nobody Thu Oct 7 21:43:14 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id AA89312D39BC for ; Thu, 7 Oct 2021 21:43:19 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.protected-networks.net (mail.protected-networks.net [IPv6:2001:470:8d59:1::8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.protected-networks.net", Issuer "R3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HQPvW0Xmwz3C1b; Thu, 7 Oct 2021 21:43:19 +0000 (UTC) (envelope-from imb@protected-networks.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= protected-networks.net; h=content-type:content-type:in-reply-to :from:from:references:content-language:subject:subject :user-agent:mime-version:date:date:message-id; s=201508; t= 1633642995; bh=EcqNfIHkYZezEIybZD15lsKBOGQgEjeRSY62qMNp740=; b=e SSZ/rSD0ggLU23OrY7vkcgAKnutwPWZUYKHnn8g0wsunyzcUIYZIDCblCXs2pHYv pHLtIbrcq1EOjoE3I0uVPbA4dBNd/FZ06+ClqNI1zs4PIP/TYE5LVdFNfN8iJgFT wwiFCgZ/l0n3OgnRHxm0hq0wSnMTuWHrbP7cDfSS+o= Received: from [192.168.1.10] (toshi.auburn.protected-networks.net [192.168.1.10]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: imb@mail.protected-networks.net) by mail.protected-networks.net (Postfix) with ESMTPSA id 2D33C2D66E; Thu, 7 Oct 2021 17:43:15 -0400 (EDT) Message-ID: Date: Thu, 7 Oct 2021 17:43:14 -0400 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Subject: Re: intermittent bsdtar/jemalloc failures Content-Language: en-NZ To: Mark Johnston Cc: Konstantin Belousov , freebsd-current References: <2908d747-8606-84d6-60b5-249c0d396b6b@protected-networks.net> <31be6e3a-f303-ce78-4dab-5dcc77ed0464@protected-networks.net> In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------NnDRKZDINBrAZUBnPASuDQOE" X-Rspamd-Queue-Id: 4HQPvW0Xmwz3C1b X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: imb@protected-networks.net From: Michael Butler via freebsd-current X-Original-From: Michael Butler X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------NnDRKZDINBrAZUBnPASuDQOE Content-Type: multipart/mixed; boundary="------------nCHRKg0TixbeTKzTLux0aV2E"; protected-headers="v1" From: Michael Butler To: Mark Johnston Cc: Konstantin Belousov , freebsd-current Message-ID: Subject: Re: intermittent bsdtar/jemalloc failures References: <2908d747-8606-84d6-60b5-249c0d396b6b@protected-networks.net> <31be6e3a-f303-ce78-4dab-5dcc77ed0464@protected-networks.net> In-Reply-To: --------------nCHRKg0TixbeTKzTLux0aV2E Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMTAvNy8yMSAxNjo1MiwgTWFyayBKb2huc3RvbiB3cm90ZToNCj4gT24gVGh1LCBPY3Qg MDcsIDIwMjEgYXQgMDQ6MTg6MjhQTSAtMDQwMCwgTWljaGFlbCBCdXRsZXIgdmlhIGZyZWVi c2QtY3VycmVudCB3cm90ZToNCj4+IE9uIDEwLzcvMjEgMTU6MzksIEtvbnN0YW50aW4gQmVs b3Vzb3Ygd3JvdGU6DQo+Pj4gT24gVGh1LCBPY3QgMDcsIDIwMjEgYXQgMDM6Mjg6NDRQTSAt MDQwMCwgTWljaGFlbCBCdXRsZXIgdmlhIGZyZWVic2QtY3VycmVudCB3cm90ZToNCj4+Pj4g V2hpbGUgYnVpbGRpbmcgYSBsb2NhbCByZWxlYXNlIGJ1bmRsZSwgSSBzb21ldGltZXMgZ2V0 IGJzZHRhciBmYWlsaW5nIChhbmQNCj4+Pj4gZHVtcGluZyBjb3JlKSBhcyBmb2xsb3dzIGJl bG93LiBXb3JzZSwgYXMgY2FuIGJlIHNlZW4gYmVsb3csIGl0IGRvZXNuJ3Qgc3RvcA0KPj4+ PiB0aGUgYnVpbGQgdW5sZXNzIEkgaGFwcGVuIHRvIG5vdGljZSBhbmQgaXQgeWllbGRzIGFu IGluY29tcGxldGUgcGFja2FnZS4NCj4+Pj4NCj4+Pj4gYSB1c3Ivc3JjL3N5cy9uZXRncmFw aC9uZ19jaGVja3N1bS5oDQo+Pj4+IGEgdXNyL3NyYy9zeXMvbmV0Z3JhcGgvbmdfbWVzc2Fn ZS5oDQo+Pj4+IGEgdXNyL3NyYy9zeXMvbmV0Z3JhcGgvbmdfZWNoby5jDQo+Pj4+IGEgdXNy L3NyYy9zeXMvbmV0Z3JhcGgvbmdfZ2lmLmgNCj4+Pj4gPGplbWFsbG9jPjogamVtYWxsb2Nf YXJlbmEuYzo3NDc6IEZhaWxlZCBhc3NlcnRpb246DQo+Pj4+ICJuc3RpbWVfY29tcGFyZSgm ZGVjYXktPmVwb2NoLCAmdGltZSkgPD0gMCINCj4+Pj4gQWJvcnQgdHJhcCAoY29yZSBkdW1w ZWQpDQo+Pj4+IHNoIC91c3Ivc3JjL3JlbGVhc2Uvc2NyaXB0cy9tYWtlLW1hbmlmZXN0LnNo ICoudHh6ID4gTUFOSUZFU1QNCj4+Pj4NCj4+Pj4gV2hhdCBjYXVzZXMgdGhpcz8gQnVpbGQg bWFjaGluZSBpcyBhIDJ4NC1jb3JlIEludGVsIGJveCB3aXRoIFpGUw0KPj4+PiBmaWxlLXN5 c3RlbXMgYWxsIGFyb3VuZC4gSSB0cmllZCBzdG9wcGluZyBOVFBEIHRlbXBvcmFyaWx5IGJ1 dCB0aGUgZmFpbHVyZXMNCj4+Pj4gcGVyc2lzdCAuLiBzb21ldGltZXMgOi0oDQo+Pj4+DQo+ Pj4+IEkndmUgc2VlbiB0aGlzIGF0IGRpZmZlcmVudCBwb2ludHMgaW4gdGhlIGFyY2hpdmlu ZyBwcm9jZXNzIHNvIGl0IGRvZXNuJ3QNCj4+Pj4gc2VlbSBzcGVjaWZpYyB0byBidWlsZGlu ZyBrZXJuZWwudHh6Lg0KPj4+DQo+Pj4gV2hhdCB0aW1lY291bnRlciBkbyB5b3UgdXNlPyBQ ZXJoYXBzIHNob3cgdGhlIHdob2xlIG91dHB1dCBmcm9tDQo+Pj4gc3lzY3RsIGtlcm4udGlt ZWNvdW50ZXIuDQo+Pg0KPj4gaW1iQHZtMDE6L2hvbWUvaW1iPiBzeXNjdGwga2Vybi50aW1l Y291bnRlcg0KPj4ga2Vybi50aW1lY291bnRlci50c2Nfc2hpZnQ6IDENCj4+IGtlcm4udGlt ZWNvdW50ZXIuc21wX3RzY19hZGp1c3Q6IDANCj4+IGtlcm4udGltZWNvdW50ZXIuc21wX3Rz YzogMQ0KPj4ga2Vybi50aW1lY291bnRlci5pbnZhcmlhbnRfdHNjOiAxDQo+PiBrZXJuLnRp bWVjb3VudGVyLmZhc3RfZ2V0dGltZTogMQ0KPj4ga2Vybi50aW1lY291bnRlci50aWNrOiAx DQo+PiBrZXJuLnRpbWVjb3VudGVyLmNob2ljZTogQUNQSS1mYXN0KDkwMCkgSFBFVCg5NTAp IGk4MjU0KDApIFRTQy1sb3coMTAwMCkNCj4+IGR1bW15KC0xMDAwMDAwKQ0KPj4ga2Vybi50 aW1lY291bnRlci5oYXJkd2FyZTogSFBFVA0KPj4ga2Vybi50aW1lY291bnRlci5hbGxvd2Vk ZGV2aWF0aW9uOiA1DQo+PiBrZXJuLnRpbWVjb3VudGVyLnRpbWVoYW5kc19jb3VudDogMg0K Pj4ga2Vybi50aW1lY291bnRlci5zdGVwd2FybmluZ3M6IDANCj4+IGtlcm4udGltZWNvdW50 ZXIudGMuQUNQSS1mYXN0LnF1YWxpdHk6IDkwMA0KPj4ga2Vybi50aW1lY291bnRlci50Yy5B Q1BJLWZhc3QuZnJlcXVlbmN5OiAzNTc5NTQ1DQo+PiBrZXJuLnRpbWVjb3VudGVyLnRjLkFD UEktZmFzdC5jb3VudGVyOiAxNjEyNDg5Mg0KPj4ga2Vybi50aW1lY291bnRlci50Yy5BQ1BJ LWZhc3QubWFzazogMTY3NzcyMTUNCj4+IGtlcm4udGltZWNvdW50ZXIudGMuSFBFVC5xdWFs aXR5OiA5NTANCj4+IGtlcm4udGltZWNvdW50ZXIudGMuSFBFVC5mcmVxdWVuY3k6IDE0MzE4 MTgwDQo+PiBrZXJuLnRpbWVjb3VudGVyLnRjLkhQRVQuY291bnRlcjogMTg4Mzk5NTIyOQ0K Pj4ga2Vybi50aW1lY291bnRlci50Yy5IUEVULm1hc2s6IDQyOTQ5NjcyOTUNCj4+IGtlcm4u dGltZWNvdW50ZXIudGMuaTgyNTQucXVhbGl0eTogMA0KPj4ga2Vybi50aW1lY291bnRlci50 Yy5pODI1NC5mcmVxdWVuY3k6IDExOTMxODINCj4+IGtlcm4udGltZWNvdW50ZXIudGMuaTgy NTQuY291bnRlcjogNTcNCj4+IGtlcm4udGltZWNvdW50ZXIudGMuaTgyNTQubWFzazogNjU1 MzUNCj4+IGtlcm4udGltZWNvdW50ZXIudGMuVFNDLWxvdy5xdWFsaXR5OiAxMDAwDQo+PiBr ZXJuLnRpbWVjb3VudGVyLnRjLlRTQy1sb3cuZnJlcXVlbmN5OiAxNDEzMTUzMDA3DQo+PiBr ZXJuLnRpbWVjb3VudGVyLnRjLlRTQy1sb3cuY291bnRlcjogMjM1MjAwMjI5NQ0KPj4ga2Vy bi50aW1lY291bnRlci50Yy5UU0MtbG93Lm1hc2s6IDQyOTQ5NjcyOTUNCj4+DQo+PiBJIG92 ZXJyb2RlIHRoZSBkZWZhdWx0IHNlbGVjdGlvbiBvZiBjb3VudGVyLXR5cGUgYXMgTlRQRCBk cmlmdGVkIHNvDQo+PiBiYWRseSBhcyB0byByZXF1aXJlIHN0ZXBwaW5nIGFsbW9zdCBob3Vy bHkgOi0oDQo+IA0KPiBDb3VsZCB5b3Ugc2hvdyBvdXRwdXQgZnJvbQ0KPiANCj4gIyBrbGRs b2FkIGNwdWN0bA0KPiAjIGNwdWNvbnRyb2wgLWkgMHgxNSAvZGV2L2NwdWN0bDANCj4gIyBj cHVjb250cm9sIC1pIDB4MTYgL2Rldi9jcHVjdGwwDQo+IA0KPiBhcyB3ZWxsIGFzIGEgY29w eSBvZiB0aGUgZG1lc2cgYWZ0ZXIgYSBib290PyAgSSBhbSBsb29raW5nIGF0IGEgc2ltaWxh cg0KPiBwcm9ibGVtIGN1cnJlbnRseS4NCg0Kcm9vdEB2bTAxOi91c3IvaG9tZS9pbWIgIyBj cHVjb250cm9sIC1pIDB4MTUgL2Rldi9jcHVjdGwwDQpjcHVpZCBsZXZlbCAweDE1OiAweDA3 MjgwMjAyIDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAweDAwMDAwNTAzDQpyb290QHZtMDE6L3Vz ci9ob21lL2ltYiAjIGNwdWNvbnRyb2wgLWkgMHgxNiAvZGV2L2NwdWN0bDANCmNwdWlkIGxl dmVsIDB4MTY6IDB4MDcyODAyMDIgMHgwMDAwMDAwMCAweDAwMDAwMDAwIDB4MDAwMDA1MDMN Cg0KVGhpcyBpcyBhIERlbGwtMTk1MCAxLVUgYm94IHdpdGggYSBTQVMgZHJpdmUtYm94IGF0 dGFjaGVkIC4uDQoNCnJvb3RAdm0wMTovdXNyL2hvbWUvaW1iICMgbGVzcyAvdmFyL2xvZy9k bWVzZy50b2RheQ0KLS0tPDxCT09UPj4tLS0NClZFUkJPU0VfU1lTSU5JVDogRERCIG5vdCBl bmFibGVkLCBzeW1ib2wgbG9va3VwcyBkaXNhYmxlZC4NCkNvcHlyaWdodCAoYykgMTk5Mi0y MDIxIFRoZSBGcmVlQlNEIFByb2plY3QuDQpDb3B5cmlnaHQgKGMpIDE5NzksIDE5ODAsIDE5 ODMsIDE5ODYsIDE5ODgsIDE5ODksIDE5OTEsIDE5OTIsIDE5OTMsIDE5OTQNCiAgICAgICAg IFRoZSBSZWdlbnRzIG9mIHRoZSBVbml2ZXJzaXR5IG9mIENhbGlmb3JuaWEuIEFsbCByaWdo dHMgcmVzZXJ2ZWQuDQpGcmVlQlNEIGlzIGEgcmVnaXN0ZXJlZCB0cmFkZW1hcmsgb2YgVGhl IEZyZWVCU0QgRm91bmRhdGlvbi4NCkZyZWVCU0QgMTQuMC1DVVJSRU5UICMyNTYgbWFpbi00 MmRmYWQyZWYxOiBTYXQgT2N0ICAyIDA5OjQxOjM2IEVEVCAyMDIxDQogDQpyb290QHZtMDEu YXVidXJuLnByb3RlY3RlZC1uZXR3b3Jrcy5uZXQ6L3Vzci9vYmovdXNyL3NyYy9hbWQ2NC5h bWQ2NC9zeXMvVk0wMSANCmFtZDY0DQpGcmVlQlNEIGNsYW5nIHZlcnNpb24gMTIuMC4xIChn aXRAZ2l0aHViLmNvbTpsbHZtL2xsdm0tcHJvamVjdC5naXQgDQpsbHZtb3JnLTEyLjAuMS0w LWdmZWQ0MTM0MmE4MmYpDQpWVCh2Z2EpOiByZXNvbHV0aW9uIDY0MHg0ODANCkNQVTogSW50 ZWwoUikgWGVvbihSKSBDUFUgICAgICAgICAgIEU1NDQwICBAIDIuODNHSHogKDI4MjYuMzEt TUh6IA0KSzgtY2xhc3MgQ1BVKQ0KICAgT3JpZ2luPSJHZW51aW5lSW50ZWwiICBJZD0weDEw Njc2ICBGYW1pbHk9MHg2ICBNb2RlbD0weDE3ICBTdGVwcGluZz02DQogDQpGZWF0dXJlcz0w eGJmZWJmYmZmPEZQVSxWTUUsREUsUFNFLFRTQyxNU1IsUEFFLE1DRSxDWDgsQVBJQyxTRVAs TVRSUixQR0UsTUNBLENNT1YsUEFULFBTRTM2LENMRkxVU0gsRFRTLEFDUEksTU1YLEZYU1Is U1NFLFNTRTIsU1MsSFRULFRNLFBCRT4NCiANCkZlYXR1cmVzMj0weGNlM2JkPFNTRTMsRFRF UzY0LE1PTixEU19DUEwsVk1YLEVTVCxUTTIsU1NTRTMsQ1gxNix4VFBSLFBEQ00sRENBLFNT RTQuMT4NCiAgIEFNRCBGZWF0dXJlcz0weDIwMTAwODAwPFNZU0NBTEwsTlgsTE0+DQogICBB TUQgRmVhdHVyZXMyPTB4MTxMQUhGPg0KICAgVlQteDogSExULFBBVVNFDQogICBUU0M6IFAt c3RhdGUgaW52YXJpYW50LCBwZXJmb3JtYW5jZSBzdGF0aXN0aWNzDQpyZWFsIG1lbW9yeSAg PSA2ODcxOTQ3NjczNiAoNjU1MzYgTUIpDQphdmFpbCBtZW1vcnkgPSA2NTgxMTY3NzE4NCAo NjI3NjIgTUIpDQpFdmVudCB0aW1lciAiTEFQSUMiIHF1YWxpdHkgMTAwDQpBQ1BJIEFQSUMg VGFibGU6IDxERUxMICAgUEVfU0MzICA+DQpGcmVlQlNEL1NNUDogTXVsdGlwcm9jZXNzb3Ig U3lzdGVtIERldGVjdGVkOiA4IENQVXMNCkZyZWVCU0QvU01QOiAyIHBhY2thZ2UocykgeCA0 IGNvcmUocykNCnJhbmRvbTogdW5ibG9ja2luZyBkZXZpY2UuDQpTZWN1cml0eSBwb2xpY3kg bG9hZGVkOiBNQUMvbnRwZCAobWFjX250cGQpDQppb2FwaWMwOiBNQURUIEFQSUMgSUQgOCAh PSBodyBpZCAwDQppb2FwaWMwIDxWZXJzaW9uIDIuMD4gaXJxcyAwLTIzDQpMYXVuY2hpbmcg QVBzOiAzIDQgMSA2IDIgNSA3DQpUaW1lY291bnRlciAiVFNDLWxvdyIgZnJlcXVlbmN5IDE0 MTMxNTU0MDkgSHogcXVhbGl0eSAxMDAwDQpyYW5kb206IGVudHJvcHkgZGV2aWNlIGV4dGVy bmFsIGludGVyZmFjZQ0Ka2JkMSBhdCBrYmRtdXgwDQp2dHZnYTA6IDxWVCBWR0EgZHJpdmVy Pg0Kc21iaW9zMDogPFN5c3RlbSBNYW5hZ2VtZW50IEJJT1M+IGF0IGlvbWVtIDB4ZmNkZjAt MHhmY2UwZQ0Kc21iaW9zMDogVmVyc2lvbjogMi41LCBCQ0QgUmV2aXNpb246IDIuNQ0KYWNw aTA6IDxERUxMIFBFX1NDMz4NCmFjcGkwOiBQb3dlciBCdXR0b24gKGZpeGVkKQ0KRmlybXdh cmUgRXJyb3IgKEFDUEkpOiBDb3VsZCBub3QgcmVzb2x2ZSBzeW1ib2wgW1wxMzRfU0IuX09T Qy5DRFcxXSwgDQpBRV9OT1RfRk9VTkQgKDIwMjEwOTMwL3BzYXJncy01MDMpDQpBQ1BJIEVy cm9yOiBBYm9ydGluZyBtZXRob2QgXDEzNF9TQi5fT1NDIGR1ZSB0byBwcmV2aW91cyBlcnJv ciANCihBRV9OT1RfRk9VTkQpICgyMDIxMDkzMC9wc3BhcnNlLTY4OSkNCmFwZWkwOiA8QUNQ SSBQbGF0Zm9ybSBFcnJvciBJbnRlcmZhY2U+IG9uIGFjcGkwDQppcG1pMDogPElQTUkgU3lz dGVtIEludGVyZmFjZT4gcG9ydCAweGNhOCwweGNhYyBvbiBhY3BpMA0KaXBtaTA6IEtDUyBt b2RlIGZvdW5kIGF0IGlvIDB4Y2E4IG9uIGFjcGkNCmNwdTA6IDxBQ1BJIENQVT4gb24gYWNw aTANCmF0cnRjMDogPEFUIHJlYWx0aW1lIGNsb2NrPiBwb3J0IDB4NzAtMHg3ZiBpcnEgOCBv biBhY3BpMA0KYXRydGMwOiByZWdpc3RlcmVkIGFzIGEgdGltZS1vZi1kYXkgY2xvY2ssIHJl c29sdXRpb24gMS4wMDAwMDBzDQpFdmVudCB0aW1lciAiUlRDIiBmcmVxdWVuY3kgMzI3Njgg SHogcXVhbGl0eSAwDQphdHRpbWVyMDogPEFUIHRpbWVyPiBwb3J0IDB4NDAtMHg1ZiBpcnEg MCBvbiBhY3BpMA0KVGltZWNvdW50ZXIgImk4MjU0IiBmcmVxdWVuY3kgMTE5MzE4MiBIeiBx dWFsaXR5IDANCkV2ZW50IHRpbWVyICJpODI1NCIgZnJlcXVlbmN5IDExOTMxODIgSHogcXVh bGl0eSAxMDANCmhwZXQwOiA8SGlnaCBQcmVjaXNpb24gRXZlbnQgVGltZXI+IGlvbWVtIDB4 ZmVkMDAwMDAtMHhmZWQwMDNmZiBvbiBhY3BpMA0KVGltZWNvdW50ZXIgIkhQRVQiIGZyZXF1 ZW5jeSAxNDMxODE4MCBIeiBxdWFsaXR5IDk1MA0KRXZlbnQgdGltZXIgIkhQRVQiIGZyZXF1 ZW5jeSAxNDMxODE4MCBIeiBxdWFsaXR5IDM1MA0KRXZlbnQgdGltZXIgIkhQRVQxIiBmcmVx dWVuY3kgMTQzMTgxODAgSHogcXVhbGl0eSAzNDANCkV2ZW50IHRpbWVyICJIUEVUMiIgZnJl cXVlbmN5IDE0MzE4MTgwIEh6IHF1YWxpdHkgMzQwDQpUaW1lY291bnRlciAiQUNQSS1mYXN0 IiBmcmVxdWVuY3kgMzU3OTU0NSBIeiBxdWFsaXR5IDkwMA0KYWNwaV90aW1lcjA6IDwyNC1i aXQgdGltZXIgYXQgMy41Nzk1NDVNSHo+IHBvcnQgMHg4MDgtMHg4MGIgb24gYWNwaTANCnBj aWIwOiA8QUNQSSBIb3N0LVBDSSBicmlkZ2U+IHBvcnQgMHhjZjgtMHhjZmYgb24gYWNwaTAN CnBjaTA6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIwDQpwY2liMTogPEFDUEkgUENJLVBDSSBi cmlkZ2U+IGF0IGRldmljZSAyLjAgb24gcGNpMA0KcGNpMTogPEFDUEkgUENJIGJ1cz4gb24g cGNpYjENCnBjaWIyOiA8QUNQSSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDAuMCBvbiBw Y2kxDQpwY2kyOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMg0KcGNpYjM6IDxBQ1BJIFBDSS1Q Q0kgYnJpZGdlPiBhdCBkZXZpY2UgMC4wIG9uIHBjaTINCnBjaTM6IDxBQ1BJIFBDSSBidXM+ IG9uIHBjaWIzDQpwY2liNDogPFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMC4wIG9uIHBj aTMNCnBjaTQ6IDxQQ0kgYnVzPiBvbiBwY2liNA0KYmNlMDogPFFMb2dpYyBOZXRYdHJlbWUg SUkgQkNNNTcwOCAxMDAwQmFzZS1UIChCMik+IG1lbSANCjB4ZjQwMDAwMDAtMHhmNWZmZmZm ZiBpcnEgMTYgYXQgZGV2aWNlIDAuMCBvbiBwY2k0DQptaWlidXMwOiA8TUlJIGJ1cz4gb24g YmNlMA0KYnJncGh5MDogPEJDTTU3MDhDIDEwMDBCQVNFLVQgbWVkaWEgaW50ZXJmYWNlPiBQ SFkgMSBvbiBtaWlidXMwDQpicmdwaHkwOiAgMTBiYXNlVCwgMTBiYXNlVC1GRFgsIDEwMGJh c2VUWCwgMTAwYmFzZVRYLUZEWCwgMTAwMGJhc2VULCANCjEwMDBiYXNlVC1tYXN0ZXIsIDEw MDBiYXNlVC1GRFgsIDEwMDBiYXNlVC1GRFgtbWFzdGVyLCBhdXRvLCBhdXRvLWZsb3cNCmJj ZTA6IFVzaW5nIGRlZmF1bHRzIGZvciBUU086IDY1NTE4LzM1LzIwNDgNCmJjZTA6IEV0aGVy bmV0IGFkZHJlc3M6IDAwOjFlOmM5OmIyOjc1OjZlDQpiY2UwOiBBU0lDICgweDU3MDgxMDIw KTsNCmJjZTA6IGxpbmsgc3RhdGUgY2hhbmdlZCB0byBET1dODQpSZXYgKEIyKTsgQnVzIChQ Q0ktWCwgNjQtYml0LCAxMzNNSHopOyBCL0MgKDcuNC4wKTsgQnVmcyANCihSWDoyO1RYOjI7 UEc6OCk7IEZsYWdzIChTUExUfE1TSXxNRlcpOyBNRlcgKFVNUCAxLjEuOSkNCkNvYWwgKFJY OjYsNiwxOCwxODsgVFg6MjAsMjAsODAsODApDQpwY2liNTogPEFDUEkgUENJLVBDSSBicmlk Z2U+IGF0IGRldmljZSAxLjAgb24gcGNpMg0KcGNpNTogPEFDUEkgUENJIGJ1cz4gb24gcGNp YjUNCnBjaWI2OiA8UENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSAwLjMgb24gcGNpMQ0KcGNp NjogPFBDSSBidXM+IG9uIHBjaWI2DQpwY2liNzogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0 IGRldmljZSAzLjAgb24gcGNpMA0KcGNpNzogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjcNCm1w dDA6IDxMU0lMb2dpYyBTQVMvU0FUQSBBZGFwdGVyPiBwb3J0IDB4ZWMwMC0weGVjZmYgbWVt IA0KMHhmYzZmYzAwMC0weGZjNmZmZmZmLDB4ZmM2ZTAwMDAtMHhmYzZlZmZmZiBpcnEgMTYg YXQgZGV2aWNlIDAuMCBvbiBwY2k3DQptcHQwOiBNUEkgVmVyc2lvbj0xLjUuMTguMA0KbXB0 MDogQ2FwYWJpbGl0aWVzOiAoIFJBSUQtMCBSQUlELTFFIFJBSUQtMSApDQptcHQwOiAxIEFj dGl2ZSBWb2x1bWUgKDIgTWF4KQ0KbXB0MDogMiBIaWRkZW4gRHJpdmUgTWVtYmVycyAoMTQg TWF4KQ0KcGNpYjg6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgNC4wIG9uIHBj aTANCm1wdDA6dm9sMChtcHQwOjA6MCk6IHBjaTg6IDxBQ1BJIFBDSSBidXM+U2V0dGluZ3Mg KCBNZW1iZXItV0NFIA0KSG90LVBsdWctU3BhcmVzIEhpZ2gtUHJpb3JpdHktUmVTeW5jICkN Cm1wdDA6dm9sMChtcHQwOjA6MCk6IFVzaW5nIFNwYXJlIFBvb2w6IDANCm1wdDA6dm9sMCht cHQwOjA6MCk6ICBvbiBwY2liOA0KQVZBR08gTWVnYVJBSUQgU0FTIEZyZWVCU0QgbXJzYXMg ZHJpdmVyIHZlcnNpb246IDA3LjcwOS4wNC4wMC1mYnNkDQoyIE1lbWJlcnM6DQogICAgICAg KG1wdDA6MToxOjApOiBQcmltYXJ5IE9ubGluZQ0KICAgICAgIChtcHQwOjE6OTowKTogU2Vj b25kYXJ5IE9ubGluZQ0KbXB0MDp2b2wwKG1wdDA6MDowKTogUkFJRC0xIC0gT3B0aW1hbA0K bXB0MDp2b2wwKG1wdDA6MDowKTogU3RhdHVzICggRW5hYmxlZCApDQoobXB0MDp2b2wwOjAp OiBtcnNhczA6IDxBVkFHTyBUaHVuZGVyYm9sdCBTQVMgQ29udHJvbGxlcj5QaHlzaWNhbCAN CihtcHQwOjA6MTowKSwgUGFzcy10aHJ1IChtcHQwOjE6MDowKQ0KKG1wdDA6dm9sMDowKTog T25saW5lDQoobXB0MDp2b2wwOjEpOiBQaHlzaWNhbCAobXB0MDowOjk6MCksIFBhc3MtdGhy dSAobXB0MDoxOjE6MCkNCiAgcG9ydCAweGRjMDAtMHhkY2ZmIG1lbSAweGZjNGRjMDAwLTB4 ZmM0ZGZmZmYsMHhmYzQ4MDAwMC0weGZjNGJmZmZmIGlycSANCjE2IGF0IGRldmljZSAwLjAo bXB0MDp2b2wwOjEpOiBPbmxpbmUNCihub3BlcmlwaDptcHQwOjE6LTE6ZmZmZmZmZmYpOiBy ZXNjYW4gYWxyZWFkeSBxdWV1ZWQNCiAgb24gcGNpOA0KbXJzYXMwOiBGVyBub3cgaW4gUmVh ZHkgc3RhdGUNCm1yc2FzMDogVXNpbmcgTVNJLVggd2l0aCA4IG51bWJlciBvZiB2ZWN0b3Jz DQptcnNhczA6IEZXIHN1cHBvcnRzIDwxNj4gTVNJWCB2ZWN0b3IsT25saW5lIENQVSA4IEN1 cnJlbnQgTVNJWCA8OD4NCm1yc2FzMDogbXJzYXNfaW5pdF9hZGFwdGVyOiBzYy0+cmVwbHlf cV9kZXB0aCAweDdlMCxzYy0+cmVxdWVzdF9hbGxvY19zeiANCjB4MWY3OCwgc2MtPnJlcGx5 X2FsbG9jX3N6IDB4M2YwMCxzYy0+aW9fZnJhbWVzX2FsbG9jX3N6IDB4M2YxMDANCm1yc2Fz MDogbWF4IHNnZTogMHg0NiwgbWF4IGNoYWluIGZyYW1lIHNpemU6IDB4NDAwLCBtYXggZncg Y21kOiAweDNlZiANCnNjLT5jaGFpbl9mcmFtZXNfYWxsb2Nfc3o6IDB4ZmJjMDANCm1yc2Fz MDogSXNzdWluZyBJT0MgSU5JVCBjb21tYW5kIHRvIEZXLg0KbXJzYXMwOiBJT0MgSU5JVCBy ZXNwb25zZSByZWNlaXZlZCBmcm9tIEZXLg0KbXJzYXMwOiBWRCBjcmVhdGVkIHRhcmdldCBJ RDogMHgwDQptcnNhczA6IFZEIGNyZWF0ZWQgdGFyZ2V0IElEOiAweDENCm1yc2FzMDogVkQg Y3JlYXRlZCB0YXJnZXQgSUQ6IDB4Mg0KbXJzYXMwOiBWRCBjcmVhdGVkIHRhcmdldCBJRDog MHgzDQptcnNhczA6IG1heF9md19jbWRzOiAxMDA3ICBtYXhfc2NzaV9jbWRzOiA5OTENCm1y c2FzMDogTVNJLXggaW50ZXJydXB0cyBzZXR1cCBzdWNjZXNzDQptcnNhczA6IG1yc2FzX29j cl90aHJlYWQNCnBjaWI5OiA8UENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSA1LjAgb24gcGNp MA0KcGNpOTogPFBDSSBidXM+IG9uIHBjaWI5DQpwY2liMTA6IDxBQ1BJIFBDSS1QQ0kgYnJp ZGdlPiBhdCBkZXZpY2UgNi4wIG9uIHBjaTANCnBjaTEwOiA8QUNQSSBQQ0kgYnVzPiBvbiBw Y2liMTANCnBjaWIxMTogPFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgNy4wIG9uIHBjaTAN CnBjaTExOiA8UENJIGJ1cz4gb24gcGNpYjExDQpwY2liMTI6IDxBQ1BJIFBDSS1QQ0kgYnJp ZGdlPiBhdCBkZXZpY2UgMjguMCBvbiBwY2kwDQpwY2kxMjogPEFDUEkgUENJIGJ1cz4gb24g cGNpYjEyDQpwY2liMTM6IDxQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDAuMCBvbiBwY2kx Mg0KcGNpMTM6IDxQQ0kgYnVzPiBvbiBwY2liMTMNCmJjZTE6IDxRTG9naWMgTmV0WHRyZW1l IElJIEJDTTU3MDggMTAwMEJhc2UtVCAoQjIpPiBtZW0gDQoweGY4MDAwMDAwLTB4ZjlmZmZm ZmYgaXJxIDE2IGF0IGRldmljZSAwLjAgb24gcGNpMTMNCm1paWJ1czE6IDxNSUkgYnVzPiBv biBiY2UxDQpicmdwaHkxOiA8QkNNNTcwOEMgMTAwMEJBU0UtVCBtZWRpYSBpbnRlcmZhY2U+ IFBIWSAxIG9uIG1paWJ1czENCmJyZ3BoeTE6ICAxMGJhc2VULCAxMGJhc2VULUZEWCwgMTAw YmFzZVRYLCAxMDBiYXNlVFgtRkRYLCAxMDAwYmFzZVQsIA0KMTAwMGJhc2VULW1hc3Rlciwg MTAwMGJhc2VULUZEWCwgMTAwMGJhc2VULUZEWC1tYXN0ZXIsIGF1dG8sIGF1dG8tZmxvdw0K YmNlMTogVXNpbmcgZGVmYXVsdHMgZm9yIFRTTzogNjU1MTgvMzUvMjA0OA0KYmNlMTogRXRo ZXJuZXQgYWRkcmVzczogMDA6MWU6Yzk6YjI6NzU6NmMNCmJjZTE6IEFTSUMgKDB4NTcwODEw MjApOw0KYmNlMTogbGluayBzdGF0ZSBjaGFuZ2VkIHRvIERPV04NClJldiAoQjIpOyBCdXMg KFBDSS1YLCA2NC1iaXQsIDEzM01Ieik7IEIvQyAoNy40LjApOyBCdWZzIA0KKFJYOjI7VFg6 MjtQRzo4KTsgRmxhZ3MgKFNQTFR8TVNJfE1GVyk7IE1GVyAoVU1QIDEuMS45KQ0KQ29hbCAo Ulg6Niw2LDE4LDE4OyBUWDoyMCwyMCw4MCw4MCkNCnVoY2kwOiA8SW50ZWwgNjMxWEVTQi82 MzJYRVNCLzMxMDAgVVNCIGNvbnRyb2xsZXIgVVNCLTE+IHBvcnQgDQoweGJjZTAtMHhiY2Zm IGlycSAyMSBhdCBkZXZpY2UgMjkuMCBvbiBwY2kwDQp1c2J1czAgb24gdWhjaTANCnVzYnVz MDogMTJNYnBzIEZ1bGwgU3BlZWQgVVNCIHYxLjANCnVoY2kxOiA8SW50ZWwgNjMxWEVTQi82 MzJYRVNCLzMxMDAgVVNCIGNvbnRyb2xsZXIgVVNCLTI+IHBvcnQgDQoweGJjYzAtMHhiY2Rm IGlycSAyMCBhdCBkZXZpY2UgMjkuMSBvbiBwY2kwDQp1c2J1czEgb24gdWhjaTENCnVzYnVz MTogMTJNYnBzIEZ1bGwgU3BlZWQgVVNCIHYxLjANCnVoY2kyOiA8SW50ZWwgNjMxWEVTQi82 MzJYRVNCLzMxMDAgVVNCIGNvbnRyb2xsZXIgVVNCLTM+IHBvcnQgDQoweGJjYTAtMHhiY2Jm IGlycSAyMSBhdCBkZXZpY2UgMjkuMiBvbiBwY2kwDQp1c2J1czIgb24gdWhjaTINCnVzYnVz MjogMTJNYnBzIEZ1bGwgU3BlZWQgVVNCIHYxLjANCnVoY2kzOiA8SW50ZWwgNjMxWEVTQi82 MzJYRVNCLzMxMDAgVVNCIGNvbnRyb2xsZXIgVVNCLTQ+IHBvcnQgDQoweGJjODAtMHhiYzlm IGlycSAyMCBhdCBkZXZpY2UgMjkuMyBvbiBwY2kwDQp1c2J1czMgb24gdWhjaTMNCnVzYnVz MzogMTJNYnBzIEZ1bGwgU3BlZWQgVVNCIHYxLjANCmVoY2kwOiA8SW50ZWwgNjNYWEVTQiBV U0IgMi4wIGNvbnRyb2xsZXI+IG1lbSAweGZjODAwMDAwLTB4ZmM4MDAzZmYgaXJxIA0KMjEg YXQgZGV2aWNlIDI5Ljcgb24gcGNpMA0KdXNidXM0OiBFSENJIHZlcnNpb24gMS4wDQp1c2J1 czQgb24gZWhjaTANCnVzYnVzNDogNDgwTWJwcyBIaWdoIFNwZWVkIFVTQiB2Mi4wDQpwY2li MTQ6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMzAuMCBvbiBwY2kwDQpwY2kx NDogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjE0DQp2Z2FwY2kwOiA8VkdBLWNvbXBhdGlibGUg ZGlzcGxheT4gcG9ydCAweGNjMDAtMHhjY2ZmIG1lbSANCjB4ZDgwMDAwMDAtMHhkZmZmZmZm ZiwweGZjMmQwMDAwLTB4ZmMyZGZmZmYgaXJxIDE5IGF0IGRldmljZSAxMy4wIG9uIHBjaTE0 DQp2Z2FwY2kwOiBCb290IHZpZGVvIGRldmljZQ0KaXNhYjA6IDxQQ0ktSVNBIGJyaWRnZT4g YXQgZGV2aWNlIDMxLjAgb24gcGNpMA0KaXNhMDogPElTQSBidXM+IG9uIGlzYWIwDQphdGFw Y2kwOiA8SW50ZWwgNjNYWEVTQjIgVURNQTEwMCBjb250cm9sbGVyPiBwb3J0IA0KMHgxZjAt MHgxZjcsMHgzZjYsMHgxNzAtMHgxNzcsMHgzNzYsMHhmYzAwLTB4ZmMwZiBhdCBkZXZpY2Ug MzEuMSBvbiBwY2kwDQphdGEwOiA8QVRBIGNoYW5uZWw+IGF0IGNoYW5uZWwgMCBvbiBhdGFw Y2kwDQp1YXJ0MDogPDE2NTUwIG9yIGNvbXBhdGlibGU+IHBvcnQgMHgzZjgtMHgzZmYgaXJx IDQgZmxhZ3MgMHgxMCBvbiBhY3BpMA0KdWFydDE6IDwxNjU1MCBvciBjb21wYXRpYmxlPiBw b3J0IDB4MmY4LTB4MmZmIGlycSAzIG9uIGFjcGkwDQp0cG0wOiA8VHJ1c3RlZCBQbGF0Zm9y bSBNb2R1bGU+IGlvbWVtIDB4ZmVkNDAwMDAtMHhmZWQ0NGZmZiBvbiBhY3BpMA0KdHBtOiBk ZXZpY2UgMHg0YTEwMDAwMCByZXYgMHg0ZQ0KV0FSTklORzogRGV2aWNlICJ0cG0iIGlzIEdp YW50IGxvY2tlZCBhbmQgbWF5IGJlIGRlbGV0ZWQgYmVmb3JlIEZyZWVCU0QgDQoxNC4wLg0K aWNod2QwOiA8SW50ZWwgNjNYWEVTQiB3YXRjaGRvZyB0aW1lcj4gb24gaXNhMA0Kb3JtMDog PElTQSBPcHRpb24gUk9Ncz4gYXQgaW9tZW0gMHhjMDAwMC0weGM4ZmZmLDB4ZWMwMDAtMHhl ZmZmZiBwbnBpZCANCk9STTAwMDAgb24gaXNhMA0KYXRrYmRjMDogPEtleWJvYXJkIGNvbnRy b2xsZXIgKGk4MDQyKT4gYXQgcG9ydCAweDYwLDB4NjQgb24gaXNhMA0KYXRrYmQwOiA8QVQg S2V5Ym9hcmQ+IGlycSAxIG9uIGF0a2JkYzANCmtiZDAgYXQgYXRrYmQwDQphdGtiZDA6IFtH SUFOVC1MT0NLRURdDQpjb3JldGVtcDA6IDxDUFUgT24tRGllIFRoZXJtYWwgU2Vuc29ycz4g b24gY3B1MA0KZXN0MDogPEVuaGFuY2VkIFNwZWVkU3RlcCBGcmVxdWVuY3kgQ29udHJvbD4g b24gY3B1MA0KVGltZWNvdW50ZXJzIHRpY2sgZXZlcnkgMS4wMDAgbXNlYw0KWkZTIGZpbGVz eXN0ZW0gdmVyc2lvbjogNQ0KWkZTIHN0b3JhZ2UgcG9vbCB2ZXJzaW9uOiBmZWF0dXJlcyBz dXBwb3J0ICg1MDAwKQ0KV0FSTklORzogQWRkaW5nIGlmYWRkcnMgdG8gYWxsIGZpYnMgaGFz IGJlZW4gdHVybmVkIG9mZiBieSBkZWZhdWx0LiANCkNvbnNpZGVyIHR1bmluZyBuZXQuYWRk X2FkZHJfYWxsZmlicyBpZiBuZWVkZWQNCmlwbWkwOiBJUE1JIGRldmljZSByZXYuIDAsIGZp cm13YXJlIHJldi4gMi41MCwgdmVyc2lvbiAyLjAsIGRldmljZSANCnN1cHBvcnQgbWFzayAw eGRmDQoocHJvYmUxNjptcHQwOjE6MTowKTogSU5RVUlSWS4gQ0RCOiAxMiAwMCAwMCAwMCAy NCAwMA0KKHByb2JlMTY6bXB0MDoxOjE6MCk6IENBTSBzdGF0dXM6IFVucmVjb3ZlcmFibGUg SG9zdCBCdXMgQWRhcHRlciBFcnJvcg0KKHByb2JlMTY6bXB0MDoxOjE6MCk6IFJldHJ5aW5n IGNvbW1hbmQsIDMgbW9yZSB0cmllcyByZW1haW4NCihwcm9iZTA6bXB0MDowOjA6MCk6IFJF UE9SVCBMVU5TLiBDREI6IGEwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDAwIDEwIDAwIDAwDQoo cHJvYmUwOm1wdDA6MDowOjApOiBDQU0gc3RhdHVzOiBTQ1NJIFN0YXR1cyBFcnJvcg0KKHBy b2JlMDptcHQwOjA6MDowKTogU0NTSSBzdGF0dXM6IENoZWNrIENvbmRpdGlvbg0KKHByb2Jl MDptcHQwOjA6MDowKTogU0NTSSBzZW5zZTogSUxMRUdBTCBSRVFVRVNUIGFzYzpmZmZmZmZm ZixmZmZmZmZmZiANCihSZXNlcnZlZCBBU0MvQVNDUSBwYWlyKQ0KKHByb2JlMDptcHQwOjA6 MDowKTogRXJyb3IgMjIsIFVucmV0cnlhYmxlIGVycm9yDQppcG1pMDogTnVtYmVyIG9mIGNo YW5uZWxzIDQNCmlwbWkwOiBBdHRhY2hlZCB3YXRjaGRvZw0KKHByb2JlMTY6bXB0MDoxOjE6 MCk6IElOUVVJUlkuIENEQjogMTIgMDAgMDAgMDAgMjQgMDANCmlwbWkwOiBFc3RhYmxpc2hp bmcgcG93ZXIgY3ljbGUgaGFuZGxlcg0KKHByb2JlMTY6bXB0MDoxOjE6MCk6IENBTSBzdGF0 dXM6IFVucmVjb3ZlcmFibGUgSG9zdCBCdXMgQWRhcHRlciBFcnJvcg0KKHByb2JlMTY6bXB0 MDoxOjE6MCk6IFJldHJ5aW5nIGNvbW1hbmQsIDIgbW9yZSB0cmllcyByZW1haW4NCnVnZW4y LjE6IDxJbnRlbCBVSENJIHJvb3QgSFVCPiBhdCB1c2J1czINCnVnZW4zLjE6IDxJbnRlbCBV SENJIHJvb3QgSFVCPiBhdCB1c2J1czMNCnVnZW4xLjE6IDxJbnRlbCBVSENJIHJvb3QgSFVC PiBhdCB1c2J1czENCnVnZW4wLjE6IDxJbnRlbCBVSENJIHJvb3QgSFVCPiBhdCB1c2J1czAN CnVnZW40LjE6IDxJbnRlbCBFSENJIHJvb3QgSFVCPiBhdCB1c2J1czQNCihwcm9iZTE2Om1w dDA6MToxOjApOiBJTlFVSVJZLiBDREI6IDEyIDAwIDAwIDAwIDI0IDAwDQp1aHViMChwcm9i ZTE2Om1wdDA6MToxOjApOiBDQU0gc3RhdHVzOiBVbnJlY292ZXJhYmxlIEhvc3QgQnVzIEFk YXB0ZXIgRXJyb3INCiAgb24gdXNidXMwDQoocHJvYmUxNjptcHQwOjE6MTowKTogUmV0cnlp bmcgY29tbWFuZCwgMSBtb3JlIHRyaWVzIHJlbWFpbg0KKHByb2JlMTY6bXB0MDoxOjE6MCk6 IElOUVVJUlkuIENEQjogMTIgMDAgMDAgMDAgMjQgMDANCnVodWIxKHByb2JlMTY6bXB0MDox OjE6MCk6IENBTSBzdGF0dXM6IFVucmVjb3ZlcmFibGUgSG9zdCBCdXMgQWRhcHRlciBFcnJv cg0KICBvbiB1c2J1czQNCnVodWIyKHByb2JlMTY6bXB0MDoxOjE6MCk6IFJldHJ5aW5nIGNv bW1hbmQsIDAgbW9yZSB0cmllcyByZW1haW4NCiAgb24gdXNidXMzDQoocHJvYmUxNjptcHQw OjE6MTowKTogSU5RVUlSWS4gQ0RCOiAxMiAwMCAwMCAwMCAyNCAwMA0KdWh1YjMocHJvYmUx NjptcHQwOjE6MTowKTogQ0FNIHN0YXR1czogVW5yZWNvdmVyYWJsZSBIb3N0IEJ1cyBBZGFw dGVyIEVycm9yDQoocHJvYmUxNjptcHQwOjE6MTowKTogRXJyb3IgNSwgUmV0cmllcyBleGhh dXN0ZWQNCiAgb24gdXNidXMxDQp1aHViMzogPEludGVsIFVIQ0kgcm9vdCBIVUIsIGNsYXNz IDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czENCnVodWIyOiA8SW50ZWwg VUhDSSByb290IEhVQiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDE+IG9uIHVz YnVzMw0KdWh1YjE6IDxJbnRlbCBFSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAyLjAw LzEuMDAsIGFkZHIgMT4gb24gdXNidXM0DQp1aHViMDogPEludGVsIFVIQ0kgcm9vdCBIVUIs IGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxPiBvbiB1c2J1czANCnVodWI0IG9u IHVzYnVzMg0KdWh1YjQ6IDxJbnRlbCBVSENJIHJvb3QgSFVCLCBjbGFzcyA5LzAsIHJldiAx LjAwLzEuMDAsIGFkZHIgMT4gb24gdXNidXMyDQptcnNhczA6IERpc2VzdGFibGlzaCBtcnNh cyBpbnRyIGhvb2sNCmRhMSBhdCBtcnNhczAgYnVzIDAgc2NidXMyIHRhcmdldCAwIGx1biAw DQpkYTE6IDxMU0kgTVI5Mjg2Q1YtOGUgMy40Nj4gRml4ZWQgRGlyZWN0IEFjY2VzcyBTUEMt MyBTQ1NJIGRldmljZQ0KZGExOiBTZXJpYWwgTnVtYmVyIDAwMjVkNWRiYTViMWVmZGUyNWEw MGEyZDA3YjAwNTA2DQpkYTE6IDE1MC4wMDBNQi9zIHRyYW5zZmVycw0KZGExOiAxOTA3MjAw TUIgKDM5MDU5NDU2MDAgNTEyIGJ5dGUgc2VjdG9ycykNCmRhMiBhdCBtcnNhczAgYnVzIDAg c2NidXMyIHRhcmdldCAxIGx1biAwDQpkYTI6IDxMU0kgTVI5Mjg2Q1YtOGUgMy40Nj4gRml4 ZWQgRGlyZWN0IEFjY2VzcyBTUEMtMyBTQ1NJIGRldmljZQ0KZGEyOiBTZXJpYWwgTnVtYmVy IDAwZTY2N2ZmYTViM2VmZGUyNWEwMGEyZDA3YjAwNTA2DQpkYTI6IDE1MC4wMDBNQi9zIHRy YW5zZmVycw0KZGEyOiAxOTA3MjAwTUIgKDM5MDU5NDU2MDAgNTEyIGJ5dGUgc2VjdG9ycykN CmRhMyBhdCBtcnNhczAgYnVzIDAgc2NidXMyIHRhcmdldCAyIGx1biAwDQpkYTM6IDxMU0kg TVI5Mjg2Q1YtOGUgMy40Nj4gRml4ZWQgRGlyZWN0IEFjY2VzcyBTUEMtMyBTQ1NJIGRldmlj ZQ0KZGEzOiBTZXJpYWwgTnVtYmVyIDAwYjIzN2MzZmE3ODEyZTAyNWEwMGEyZDA3YjAwNTA2 DQpkYTM6IDE1MC4wMDBNQi9zIHRyYW5zZmVycw0KZGEzOiAyNzk0ODhNQiAoNTcyMzkxNDI0 IDUxMiBieXRlIHNlY3RvcnMpDQpkYTAgYXQgbXB0MCBidXMgMCBzY2J1czAgdGFyZ2V0IDAg bHVuIDANCmRhMDogPERlbGwgVklSVFVBTCBESVNLIDEwMjg+IEZpeGVkIERpcmVjdCBBY2Nl c3MgU1BDLTMgU0NTSSBkZXZpY2UNCmRhMDogMzAwLjAwME1CL3MgdHJhbnNmZXJzDQpkYTA6 IENvbW1hbmQgUXVldWVpbmcgZW5hYmxlZA0KZGEwOiAxOTA2Mzk0TUIgKDM5MDQyOTQ5MTIg NTEyIGJ5dGUgc2VjdG9ycykNCmRhNCBhdCBtcnNhczAgYnVzIDAgc2NidXMyIHRhcmdldCAz IGx1biAwDQpkYTQ6IDxMU0kgTVI5Mjg2Q1YtOGUgMy40Nj4gRml4ZWQgRGlyZWN0IEFjY2Vz cyBTUEMtMyBTQ1NJIGRldmljZQ0KZGE0OiBTZXJpYWwgTnVtYmVyIDAwYmNhZDY3ZmFjMDQ5 OGEyN2EwMGEyZDA3YjAwNTA2DQpkYTQ6IDE1MC4wMDBNQi9zIHRyYW5zZmVycw0KZGE0OiAy Mjg4NzQyNE1CICg0Njg3MzQ0NDM1MiA1MTIgYnl0ZSBzZWN0b3JzKQ0Kc2VzMCBhdCBtcHQw IGJ1cyAwIHNjYnVzMCB0YXJnZXQgOCBsdW4gMA0Kc2VzMDogPERQIEJBQ0tQTEFORSAxLjA1 PiBGaXhlZCBFbmNsb3N1cmUgU2VydmljZXMgU1BDLTMgU0NTSSBkZXZpY2UNCnNlczA6IDMw MC4wMDBNQi9zIHRyYW5zZmVycw0Kc2VzMDogU0VTIERldmljZQ0KcGFzczIgYXQgbXB0MCBi dXMgMSBzY2J1czEgdGFyZ2V0IDAgbHVuIDANCnBhc3MyOiA8QVRBIEhpdGFjaGkgSFVBNzIy MDIgQTNOSD4gRml4ZWQgVW5pbnN0YWxsZWQgU1BDLTMgU0NTSSBkZXZpY2UNCnBhc3MyOiBT ZXJpYWwgTnVtYmVyIEI4R1kyVzNaDQpwYXNzMjogMzAwLjAwME1CL3MgdHJhbnNmZXJzDQpw YXNzMjogQ29tbWFuZCBRdWV1ZWluZyBlbmFibGVkDQpjZDAgYXQgYXRhMCBidXMgMCBzY2J1 czQgdGFyZ2V0IDAgbHVuIDANCmNkMDogPEhMLURULVNUIENEUlcvRFZEIEdDQ1QxME4gQTEw Mj4gUmVtb3ZhYmxlIENELVJPTSBTQ1NJIGRldmljZQ0KY2QwOiAzMy4zMDBNQi9zIHRyYW5z ZmVycyAoVURNQTIsIEFUQVBJIDEyYnl0ZXMsIFBJTyA2NTUzNGJ5dGVzKQ0KY2QwOiBBdHRl bXB0IHRvIHF1ZXJ5IGRldmljZSBzaXplIGZhaWxlZDogTk9UIFJFQURZLCBNZWRpdW0gbm90 IHByZXNlbnQNCmh3cG1jOiBTT0ZULzE2LzY0LzB4Njc8SU5ULFVTUixTWVMsUkVBLFdSST4g VFNDLzEvNjQvMHgyMDxSRUE+IA0KSUFQLzIvNDAvMHgzZmY8SU5ULFVTUixTWVMsRURHLFRI UixSRUEsV1JJLElOVixRVUEsUFJDPiANCklBRi8zLzQwLzB4Njc8SU5ULFVTUixTWVMsUkVB LFdSST4NClRyeWluZyB0byBtb3VudCByb290IGZyb20gemZzOnpyb290L1JPT1QvZGVmYXVs dCBbXS4uLg0KUm9vdCBtb3VudCB3YWl0aW5nIGZvcjogdXNidXMwIHVzYnVzMSB1c2J1czIg dXNidXMzIHVzYnVzNA0KdWh1YjM6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBw b3dlcmVkDQp1aHViMjogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQN CnVodWIwOiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZA0KdWh1YjQ6 IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkDQpSb290IG1vdW50IHdh aXRpbmcgZm9yOiB1c2J1czQNClJvb3QgbW91bnQgd2FpdGluZyBmb3I6IHVzYnVzNA0KUm9v dCBtb3VudCB3YWl0aW5nIGZvcjogdXNidXM0DQp1aHViMTogOCBwb3J0cyB3aXRoIDggcmVt b3ZhYmxlLCBzZWxmIHBvd2VyZWQNCnVnZW40LjI6IDx2ZW5kb3IgMHg0MTNjIHByb2R1Y3Qg MHhhMDAxPiBhdCB1c2J1czQNCnVodWI1IG9uIHVodWIxDQp1aHViNTogPHZlbmRvciAweDQx M2MgcHJvZHVjdCAweGEwMDEsIGNsYXNzIDkvMCwgcmV2IDIuMDAvMC4wMCwgYWRkciAyPiAN Cm9uIHVzYnVzNA0KdWh1YjU6IE1UVCBlbmFibGVkDQpSb290IG1vdW50IHdhaXRpbmcgZm9y OiB1c2J1czQNCnVodWI1OiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJl ZA0KdWdlbjQuMzogPERlbGwgRFJBQzU+IGF0IHVzYnVzNA0KdWtiZDAgb24gdWh1YjUNCnVr YmQwOiA8S2V5Ym9hcmQ+IG9uIHVzYnVzNA0Ka2JkMiBhdCB1a2JkMA0KdW1zMCBvbiB1aHVi NQ0KdW1zMDogPE1vdXNlPiBvbiB1c2J1czQNCnVtczA6IDMgYnV0dG9ucyBhbmQgW1pdIGNv b3JkaW5hdGVzIElEPTANClJvb3QgbW91bnQgd2FpdGluZyBmb3I6IHVzYnVzNA0KdWdlbjQu NDogPHZlbmRvciAweDA0YjQgcHJvZHVjdCAweDY1NjA+IGF0IHVzYnVzNA0KdWh1YjYgb24g dWh1YjENCnVodWI2OiA8dmVuZG9yIDB4MDRiNCBwcm9kdWN0IDB4NjU2MCwgY2xhc3MgOS8w LCByZXYgMi4wMC8wLjBiLCBhZGRyIDQ+IA0Kb24gdXNidXM0DQp1aHViNjogTVRUIGVuYWJs ZWQNCnVnZW4xLjI6IDxOT1ZBVEVLIFVTQiBLZXlib2FyZD4gYXQgdXNidXMxDQp1a2JkMSBv biB1aHViMw0KdWtiZDE6IDxOT1ZBVEVLIFVTQiBLZXlib2FyZCwgY2xhc3MgMC8wLCByZXYg MS4xMC8xLjA0LCBhZGRyIDI+IG9uIHVzYnVzMQ0Ka2JkMyBhdCB1a2JkMQ0KUm9vdCBtb3Vu dCB3YWl0aW5nIGZvcjogdXNidXM0DQp1aHViNjogNCBwb3J0cyB3aXRoIDQgcmVtb3ZhYmxl LCBzZWxmIHBvd2VyZWQNCmJyaWRnZTA6IEV0aGVybmV0IGFkZHJlc3M6IDU4OjljOmZjOjEw OmZmOjkwDQp0YXAwOiBFdGhlcm5ldCBhZGRyZXNzOiA1ODo5YzpmYzoxMDpmMzo1Mw0KbG8w OiBsaW5rIHN0YXRlIGNoYW5nZWQgdG8gVVANCmJjZTA6IEdpZ2FiaXQgbGluayB1cCENCmJj ZTA6IGxpbmsgc3RhdGUgY2hhbmdlZCB0byBVUA0KYmNlMDogcHJvbWlzY3VvdXMgbW9kZSBl bmFibGVkDQpicmlkZ2UwOiBsaW5rIHN0YXRlIGNoYW5nZWQgdG8gVVANCmJjZTE6IEdpZ2Fi aXQgbGluayB1cCENCmJjZTE6IGxpbmsgc3RhdGUgY2hhbmdlZCB0byBVUA0KbmZzZDogY2Fu J3QgcmVnaXN0ZXIgc3ZjIG5hbWUNCnRhcDA6IGxpbmsgc3RhdGUgY2hhbmdlZCB0byBVUA0K W2ZpYl9hbGdvXSBpbmV0LjAgKGJzZWFyY2g0IzY3KSByZWJ1aWxkX2ZkX2ZsbTogc3dpdGNo aW5nIGFsZ28gdG8gDQpyYWRpeDRfbG9ja2xlc3MNCltmaWJfYWxnb10gaW5ldC4xIChic2Vh cmNoNCM3OSkgcmVidWlsZF9mZF9mbG06IHN3aXRjaGluZyBhbGdvIHRvIA0KcmFkaXg0X2xv Y2tsZXNzDQoNCglpbWINCg== --------------nCHRKg0TixbeTKzTLux0aV2E-- --------------NnDRKZDINBrAZUBnPASuDQOE Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wmMEABEIACMWIQRvY+Y5ncyOPpTWDwZC/2uuBELUkgUCYV9p8gUDAAAAAAAKCRBC/2uuBELUkjdO AJ4k4h4ZlM99YF/ZM+X34FL/plHZ+ACgiNdhC3qUMq1inDtJP70ev3LSJdo= =PYfe -----END PGP SIGNATURE----- --------------NnDRKZDINBrAZUBnPASuDQOE-- From nobody Fri Oct 8 00:19:59 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0F1CC17E3784 for ; Fri, 8 Oct 2021 00:20:09 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HQTNS5LdTz3PF9; Fri, 8 Oct 2021 00:20:08 +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 1980K1oP056889 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 8 Oct 2021 03:20:04 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 1980K1oP056889 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 1980Jxds056856; Fri, 8 Oct 2021 03:19:59 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 8 Oct 2021 03:19:59 +0300 From: Konstantin Belousov To: Michael Butler Cc: Mark Johnston , freebsd-current Subject: Re: intermittent bsdtar/jemalloc failures Message-ID: References: <2908d747-8606-84d6-60b5-249c0d396b6b@protected-networks.net> <31be6e3a-f303-ce78-4dab-5dcc77ed0464@protected-networks.net> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on tom.home X-Rspamd-Queue-Id: 4HQTNS5LdTz3PF9 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Thu, Oct 07, 2021 at 05:43:14PM -0400, Michael Butler wrote: > On 10/7/21 16:52, Mark Johnston wrote: > > On Thu, Oct 07, 2021 at 04:18:28PM -0400, Michael Butler via freebsd-current wrote: > > > On 10/7/21 15:39, Konstantin Belousov wrote: > > > > On Thu, Oct 07, 2021 at 03:28:44PM -0400, Michael Butler via freebsd-current wrote: > > > > > While building a local release bundle, I sometimes get bsdtar failing (and > > > > > dumping core) as follows below. Worse, as can be seen below, it doesn't stop > > > > > the build unless I happen to notice and it yields an incomplete package. > > > > > > > > > > a usr/src/sys/netgraph/ng_checksum.h > > > > > a usr/src/sys/netgraph/ng_message.h > > > > > a usr/src/sys/netgraph/ng_echo.c > > > > > a usr/src/sys/netgraph/ng_gif.h > > > > > : jemalloc_arena.c:747: Failed assertion: > > > > > "nstime_compare(&decay->epoch, &time) <= 0" > > > > > Abort trap (core dumped) > > > > > sh /usr/src/release/scripts/make-manifest.sh *.txz > MANIFEST > > > > > > > > > > What causes this? Build machine is a 2x4-core Intel box with ZFS > > > > > file-systems all around. I tried stopping NTPD temporarily but the failures > > > > > persist .. sometimes :-( > > > > > > > > > > I've seen this at different points in the archiving process so it doesn't > > > > > seem specific to building kernel.txz. > > > > > > > > What timecounter do you use? Perhaps show the whole output from > > > > sysctl kern.timecounter. > > > > > > imb@vm01:/home/imb> sysctl kern.timecounter > > > kern.timecounter.tsc_shift: 1 > > > kern.timecounter.smp_tsc_adjust: 0 > > > kern.timecounter.smp_tsc: 1 > > > kern.timecounter.invariant_tsc: 1 > > > kern.timecounter.fast_gettime: 1 > > > kern.timecounter.tick: 1 > > > kern.timecounter.choice: ACPI-fast(900) HPET(950) i8254(0) TSC-low(1000) > > > dummy(-1000000) > > > kern.timecounter.hardware: HPET > > > kern.timecounter.alloweddeviation: 5 > > > kern.timecounter.timehands_count: 2 > > > kern.timecounter.stepwarnings: 0 > > > kern.timecounter.tc.ACPI-fast.quality: 900 > > > kern.timecounter.tc.ACPI-fast.frequency: 3579545 > > > kern.timecounter.tc.ACPI-fast.counter: 16124892 > > > kern.timecounter.tc.ACPI-fast.mask: 16777215 > > > kern.timecounter.tc.HPET.quality: 950 > > > kern.timecounter.tc.HPET.frequency: 14318180 > > > kern.timecounter.tc.HPET.counter: 1883995229 > > > kern.timecounter.tc.HPET.mask: 4294967295 > > > kern.timecounter.tc.i8254.quality: 0 > > > kern.timecounter.tc.i8254.frequency: 1193182 > > > kern.timecounter.tc.i8254.counter: 57 > > > kern.timecounter.tc.i8254.mask: 65535 > > > kern.timecounter.tc.TSC-low.quality: 1000 > > > kern.timecounter.tc.TSC-low.frequency: 1413153007 > > > kern.timecounter.tc.TSC-low.counter: 2352002295 > > > kern.timecounter.tc.TSC-low.mask: 4294967295 > > > > > > I overrode the default selection of counter-type as NTPD drifted so > > > badly as to require stepping almost hourly :-( If you return to TSC, does the problem go away? Same question if you leave HPET on, but set fast_gettime to 0. From nobody Fri Oct 8 19:36:18 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 8B5DF12DEF76 for ; Fri, 8 Oct 2021 19:36:27 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.protected-networks.net (mail.protected-networks.net [202.12.127.228]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.protected-networks.net", Issuer "R3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HQz2g2Ztdz3lfr; Fri, 8 Oct 2021 19:36:27 +0000 (UTC) (envelope-from imb@protected-networks.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= protected-networks.net; h=content-transfer-encoding:content-type :content-type:in-reply-to:from:from:references:content-language :subject:subject:user-agent:mime-version:date:date:message-id; s=201508; t=1633721778; bh=bNm2qguGIGX8mTvg8FxPFG+3iuwzmnjfjPlF VA1LjYU=; b=DgfDJxlLbMKSD0bfr6qHlOUj6krIF/Y7CcSIaWl0RvpBko6STADv ejUL6SBl6zYf2mqVJAtZ/0MrAr7GsJOXAgmYy5eLfzOm+etVlrtpY+stssTL/6wN t09sgYcU3SoKV1jE/ZmIvdzNopYSAYDZ+7V1dFBWD7CGv31guMziTyw= Received: from [192.168.1.10] (toshi.auburn.protected-networks.net [192.168.1.10]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: imb@mail.protected-networks.net) by mail.protected-networks.net (Postfix) with ESMTPSA id 53B7B3C02E; Fri, 8 Oct 2021 15:36:18 -0400 (EDT) Message-ID: Date: Fri, 8 Oct 2021 15:36:18 -0400 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Subject: Re: intermittent bsdtar/jemalloc failures Content-Language: en-NZ To: Konstantin Belousov Cc: Mark Johnston , freebsd-current References: <2908d747-8606-84d6-60b5-249c0d396b6b@protected-networks.net> <31be6e3a-f303-ce78-4dab-5dcc77ed0464@protected-networks.net> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4HQz2g2Ztdz3lfr X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: imb@protected-networks.net From: Michael Butler via freebsd-current X-Original-From: Michael Butler X-ThisMailContainsUnwantedMimeParts: N On 10/7/21 20:19, Konstantin Belousov wrote: > On Thu, Oct 07, 2021 at 05:43:14PM -0400, Michael Butler wrote: >> On 10/7/21 16:52, Mark Johnston wrote: >>> On Thu, Oct 07, 2021 at 04:18:28PM -0400, Michael Butler via freebsd-current wrote: >>>> On 10/7/21 15:39, Konstantin Belousov wrote: >>>>> On Thu, Oct 07, 2021 at 03:28:44PM -0400, Michael Butler via freebsd-current wrote: >>>>>> While building a local release bundle, I sometimes get bsdtar failing (and >>>>>> dumping core) as follows below. Worse, as can be seen below, it doesn't stop >>>>>> the build unless I happen to notice and it yields an incomplete package. >>>>>> >>>>>> a usr/src/sys/netgraph/ng_checksum.h >>>>>> a usr/src/sys/netgraph/ng_message.h >>>>>> a usr/src/sys/netgraph/ng_echo.c >>>>>> a usr/src/sys/netgraph/ng_gif.h >>>>>> : jemalloc_arena.c:747: Failed assertion: >>>>>> "nstime_compare(&decay->epoch, &time) <= 0" >>>>>> Abort trap (core dumped) >>>>>> sh /usr/src/release/scripts/make-manifest.sh *.txz > MANIFEST >>>>>> >>>>>> What causes this? Build machine is a 2x4-core Intel box with ZFS >>>>>> file-systems all around. I tried stopping NTPD temporarily but the failures >>>>>> persist .. sometimes :-( >>>>>> >>>>>> I've seen this at different points in the archiving process so it doesn't >>>>>> seem specific to building kernel.txz. >>>>> >>>>> What timecounter do you use? Perhaps show the whole output from >>>>> sysctl kern.timecounter. >>>> >>>> imb@vm01:/home/imb> sysctl kern.timecounter >>>> kern.timecounter.tsc_shift: 1 >>>> kern.timecounter.smp_tsc_adjust: 0 >>>> kern.timecounter.smp_tsc: 1 >>>> kern.timecounter.invariant_tsc: 1 >>>> kern.timecounter.fast_gettime: 1 >>>> kern.timecounter.tick: 1 >>>> kern.timecounter.choice: ACPI-fast(900) HPET(950) i8254(0) TSC-low(1000) >>>> dummy(-1000000) >>>> kern.timecounter.hardware: HPET >>>> kern.timecounter.alloweddeviation: 5 >>>> kern.timecounter.timehands_count: 2 >>>> kern.timecounter.stepwarnings: 0 >>>> kern.timecounter.tc.ACPI-fast.quality: 900 >>>> kern.timecounter.tc.ACPI-fast.frequency: 3579545 >>>> kern.timecounter.tc.ACPI-fast.counter: 16124892 >>>> kern.timecounter.tc.ACPI-fast.mask: 16777215 >>>> kern.timecounter.tc.HPET.quality: 950 >>>> kern.timecounter.tc.HPET.frequency: 14318180 >>>> kern.timecounter.tc.HPET.counter: 1883995229 >>>> kern.timecounter.tc.HPET.mask: 4294967295 >>>> kern.timecounter.tc.i8254.quality: 0 >>>> kern.timecounter.tc.i8254.frequency: 1193182 >>>> kern.timecounter.tc.i8254.counter: 57 >>>> kern.timecounter.tc.i8254.mask: 65535 >>>> kern.timecounter.tc.TSC-low.quality: 1000 >>>> kern.timecounter.tc.TSC-low.frequency: 1413153007 >>>> kern.timecounter.tc.TSC-low.counter: 2352002295 >>>> kern.timecounter.tc.TSC-low.mask: 4294967295 >>>> >>>> I overrode the default selection of counter-type as NTPD drifted so >>>> badly as to require stepping almost hourly :-( > > If you return to TSC, does the problem go away? > Same question if you leave HPET on, but set fast_gettime to 0. While I've only done one build (still) with HPET with kern.timecounter.fast_gettime=0, I didn't see a core-dump. I'll test more over the weekend, imb From nobody Fri Oct 8 20:42:01 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B7E7E17E52D5 for ; Fri, 8 Oct 2021 20:42:20 +0000 (UTC) (envelope-from timp87@gmail.com) Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HR0Vg5cJ4z3rFB for ; Fri, 8 Oct 2021 20:42:19 +0000 (UTC) (envelope-from timp87@gmail.com) Received: by mail-ed1-x52a.google.com with SMTP id d3so13311556edp.3 for ; Fri, 08 Oct 2021 13:42:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rrLaITBLrYUsJhB2IksC6p8ZQVfheM5uihcXVhnQoJU=; b=SmKjC7SjeXp18Nr4Sii8BQVzf7G4x/u19sra5A2rlVoUbFlpMedzB/6GzeNqba+YIB Qs5t0d9jj6sS/5bY44Rz6ebi2FqpF+AnX7mhkdMrnyrmlK2O2emUoSA+scA42xQapQFN LvAgrF74Sdq5w2V9UXy0ICbBhhJlbCy8ZiLNY4QThKJ6TC2ijsyU7DoMQk8LpCKo2Gsi oWXo/Lb9IrsPEfy9xt7RCouo6FhDf+M+JpI9Y4q6kxLBcSPp2FehTuBFKJ32LTwlyTOt w0omfPci5hUixjjFmSIlAMQgj1xvulwr68N8DlgjxC1xNv97WAoBwWWwf47GBdVOetD3 yWmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rrLaITBLrYUsJhB2IksC6p8ZQVfheM5uihcXVhnQoJU=; b=hhrpTkHOnHa+1++T57/pQhMotpWESCN4hCXbYxLw8XnFSr65TpM6o2JDMdV9JBhvHH wU47dlB9FQYmu2U9qGcDmQMnG1vtqKxkG64ghBsjrGq+1DJslpAHm6gMLG9eLAnDioVI WJ4L64kImrvU6ZawSgJefR4g4yKZk+JQoFeT3ZvInnaVn4y1GCgGETZG/J6sveoBtQEJ vTEdkN9M0/VwC3OU5NftVIIaeSjzjzgC7v0Lyu16ryDpdrokiigOvJ0Lop6T4A80zHCp wvUAAp9EwPHsRVFKWby1EgkiVcHQNKFZuWjcfkZRNR9oXHkjjwqlMJ8Kf2M/Tz/nGYnQ Tq1w== X-Gm-Message-State: AOAM530vRXCadb6zWCSA1lTz4zqjzbjVJqqb8RH/oU9ogPZ9LcBm8QBN sQJa4CSTSLwgm47Mffle+wMwsgvg9eTRBGB1NMV1Wvj+wdY= X-Google-Smtp-Source: ABdhPJyBiu67+jMdjE4kwzFmtPM//ezqOtL6ya4kHqtrtWPHGYH45I3MbPf40BY0SXG39Yuhz7qpfuG1V0gAtncMIao= X-Received: by 2002:a05:6402:35c4:: with SMTP id z4mr17841637edc.197.1633725732804; Fri, 08 Oct 2021 13:42:12 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Pavel Timofeev Date: Fri, 8 Oct 2021 14:42:01 -0600 Message-ID: Subject: Re: Dell Latitude 7400 - nvme0: Missing interrupt To: Warner Losh Cc: Chuck Tuffli , freebsd-current Content-Type: multipart/alternative; boundary="000000000000f768a705cddd694e" X-Rspamd-Queue-Id: 4HR0Vg5cJ4z3rFB X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=SmKjC7Sj; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of timp87@gmail.com designates 2a00:1450:4864:20::52a as permitted sender) smtp.mailfrom=timp87@gmail.com X-Spamd-Result: default: False [-3.23 / 15.00]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; NEURAL_HAM_MEDIUM(-0.23)[-0.229]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52a:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_TLS_ALL(0.00)[]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org] X-ThisMailContainsUnwantedMimeParts: Y --000000000000f768a705cddd694e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =D1=81=D0=B1, 21 =D0=B0=D0=B2=D0=B3. 2021 =D0=B3. =D0=B2 15:22, Warner Losh= : > > > On Sat, Aug 21, 2021 at 3:06 PM Pavel Timofeev wrote: > >> >> >> Warner Losh : >> >>> >>> >>> On Fri, Aug 20, 2021 at 10:42 PM Pavel Timofeev >>> wrote: >>> >>>> Pavel Timofeev : >>>> >>>> > >>>> > Chuck Tuffli : >>>> > >>>> >> On Mon, Aug 16, 2021 at 7:43 PM Pavel Timofeev >>>> wrote: >>>> >> > >>>> >> > Hello >>>> >> > I've got a Dell Latitude 7400 and tried installing the latest >>>> >> 14.0-CURRENT >>>> >> > (main-n248636-d20e9e02db3) on it. >>>> >> > Despite other things the weird one which concerns me is >>>> >> > nvme0: Missing interrupt >>>> >> > message I get sometimes on the console. >>>> >> > It seems like I get it only after the reboot of the laptop, i. e. >>>> not >>>> >> > getting that message if I power cycle the laptop, at least I >>>> haven't >>>> >> seen >>>> >> > them for now in such cases. >>>> >> > So when the laptop is rebooted I can't even take advantage of >>>> >> > nvmecontrol(8) quickly. >>>> >> > Well, it still works, but it takes tens of seconds to return the >>>> output. >>>> >> ... >>>> >> > dmesg when power cycled - >>>> >> > https://drive.google.com/file/d/1dB27oB1O2CcnZy6DvOOhmFO8SN8V8SwJ >>>> >> > dmesg when rebooted - >>>> >> > https://drive.google.com/file/d/1DsKTMkihp_OmUcirByLaVO4o2mU38Bxh >>>> >> >>>> >> I'm sort of curious about the time stamps for the log messages in t= he >>>> >> failing case. Something like: >>>> >> >>>> >> $ grep "nv\(me\|d\)" /var/log/messages >>>> >> >>>> >> --chuck >>>> >> >>>> > >>>> > Well, I can't see timestamps in the verbose boot log. Am I missing >>>> some >>>> > configuration for that? >>>> > >>>> > $ grep "nv\(me\|d\)" /var/log/messages >>>> > nvme0: mem >>>> > 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff at >>>> device >>>> > 0.0 on pci6 >>>> > nvme0: attempting to allocate 5 MSI-X vectors (17 supported) >>>> > nvme0: using IRQs 133-137 for MSI-X >>>> > nvme0: CapLo: 0x140103ff: MQES 1023, CQR, TO 20 >>>> > nvme0: CapHi: 0x00000030: DSTRD 0, NSSRS, CSS 1, MPSMIN 0, MPSMAX 0 >>>> > nvme0: Version: 0x00010300: 1.3 >>>> > nvme0: Missing interrupt >>>> > nvme0: Missing interrupt >>>> > nvme0: Missing interrupt >>>> > nvme0: Missing interrupt >>>> > nvme0: Missing interrupt >>>> > nvme0: Missing interrupt >>>> > nvme0: Missing interrupt >>>> > nvme0: Missing interrupt >>>> > nvme0: Missing interrupt >>>> > nvme0: Missing interrupt >>>> > nvme0: Missing interrupt >>>> > nvme0: Missing interrupt >>>> > nvd0: NVMe namespace >>>> > GEOM: new disk nvd0 >>>> > nvd0: 488386MB (1000215216 512 byte sectors) >>>> > >>>> >>>> >>>> Ah, sorry, provided wrong output. >>>> Here is what you requested: >>>> $ grep "nv\(me\|d\)" /var/log/messages >>>> Aug 21 04:34:36 nostromo kernel: nvme0: mem >>>> 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff at >>>> device >>>> 0.0 on pci6 >>>> Aug 21 04:34:36 nostromo kernel: nvme0: attempting to allocate 5 MSI-X >>>> vectors (17 supported) >>>> Aug 21 04:34:36 nostromo kernel: nvme0: using IRQs 133-137 for MSI-X >>>> Aug 21 04:34:36 nostromo kernel: nvme0: CapLo: 0x140103ff: MQES 1023, >>>> CQR, >>>> TO 20 >>>> Aug 21 04:34:36 nostromo kernel: nvme0: CapHi: 0x00000030: DSTRD 0, >>>> NSSRS, >>>> CSS 1, MPSMIN 0, MPSMAX 0 >>>> Aug 21 04:34:36 nostromo kernel: nvme0: Version: 0x00010300: 1.3 >>>> Aug 21 04:34:36 nostromo kernel: nvme0: Missing interrupt >>>> Aug 21 04:34:36 nostromo kernel: nvme0: Missing interrupt >>>> Aug 21 04:34:36 nostromo kernel: nvme0: Missing interrupt >>>> Aug 21 04:34:36 nostromo kernel: nvd0: NVM= e >>>> namespace >>>> Aug 21 04:34:36 nostromo kernel: GEOM: new disk nvd0 >>>> Aug 21 04:34:36 nostromo kernel: nvd0: 488386MB (1000215216 512 byte >>>> sectors) >>>> Aug 21 04:34:42 nostromo kernel: nvme0: Missing interrupt >>>> Aug 21 04:35:36 nostromo kernel: nvme0: Missing interrupt >>>> Aug 21 04:35:50 nostromo kernel: nvme0: Missing interrupt >>>> >>> >>> What happens if you set hw.nvme.use_nvd=3D0 and hw.cam.nda.nvd_compat= =3D1 >>> in the boot loader and reboot? Same thing except nda where nvd was? Or >>> does >>> it work? >>> >>> Something weird is going on in the interrupt assignment, I think, but I >>> wanted to get any nvd vs nda issues out of the way first. >>> >>> Warner >>> >> >> Do you mean kern.cam.nda.nvd_compat instead of hw.cam.nda.nvd_compat? >> kern.cam.nda.nvd_compat is 1 by default now. >> >> So I tried to set hw.nvme.use_nvd to 1 as suggested, but I still see >> nvme0: Missing interrupt >> and now also >> Root mount waiting for: CAM >> messages besides those >> > > OK. That all makes sense. I'd forgotten that nvd_compat=3D1 by default th= ese > days. > > I'll take a look on monday starting at the differences in interrupt > assignment that > are apparent when you cold boot vs reboot. > > Thanks for checking... I'd hoped this was a cheap fix, but also didn't > really > expect it to be. > > Warner > > I've recently upgraded to main-n249974-17f790f49f5 and it got even worse now. So clean poweron works as before. But if rebooted nvme drive refuses to work, while before the code upgrade it was just complaining about missing interrupts. currently dmesg show this: nvme0: mem 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff at device 0.0 on pci6 nvd0: NVMe namespace nvd0: 488386MB (1000215216 512 byte sectors) nvme0: mem 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff at device 0.0 on pci6 nvme0: RECOVERY_START 9585870784 vs 9367036288 nvme0: timeout with nothing complete, resetting nvme0: Resetting controller due to a timeout. nvme0: RECOVERY_WAITING nvme0: resetting controller nvme0: aborting outstanding admin command nvme0: IDENTIFY (06) sqid:0 cid:15 nsid:0 cdw10:00000001 cdw11:00000000 nvme0: ABORTED - BY REQUEST (00/07) sqid:0 cid:15 cdw0:0 nvme0: nvme_identify_controller failed! nvme0: waiting nvme0: mem 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff at device 0.0 on pci6 nvme0: RECOVERY_START 9362778467 vs 9361830561 nvme0: timeout with nothing complete, resetting nvme0: Resetting controller due to a timeout. nvme0: RECOVERY_WAITING nvme0: resetting controller nvme0: aborting outstanding admin command nvme0: IDENTIFY (06) sqid:0 cid:15 nsid:0 cdw10:00000001 cdw11:00000000 nvme0: ABORTED - BY REQUEST (00/07) sqid:0 cid:15 cdw0:0 nvme0: nvme_identify_controller failed! nvme0: waiting --000000000000f768a705cddd694e-- From nobody Fri Oct 8 20:49:02 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9D71317E7323 for ; Fri, 8 Oct 2021 20:49:14 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ua1-x92a.google.com (mail-ua1-x92a.google.com [IPv6:2607:f8b0:4864:20::92a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HR0ff3hSMz3sgx for ; Fri, 8 Oct 2021 20:49:14 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ua1-x92a.google.com with SMTP id i8so7593551uae.7 for ; Fri, 08 Oct 2021 13:49:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=G2T6xixbR51gXles+5J8VZj8KNxOGhVd1Fzhsy9f65o=; b=LyPxlAL5+7th1ijv77nkYBMBZVjV8MlKWxasGhmGInfj6QCzPIhZK+Q/tJuofj3NQE QeqolXco5gBC3OBrBuiXWkFLX70oTDYcwHwr+5wkG1pO1xmk7KwmL8fbrQWhxAA59Pkp 3Q9mqWLt8WNmYhn15kQZcUQM75unpLWwcFT5Bu7TIci4VluiPjZuIqlR0nTdKgB7UwmB Y06xh+ii3Pkr2sp7/Q0A2m6rA4LMqAeTe/lwomS+liEQLAHNessn+DhS0b/XuUGHf8pW b6Gox8IMM8VekUNYHfEsZAMlp/x/LmHNx1VJggfbv1AM3Yz1GLRR536n/fty7/rAbmuY w9fw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=G2T6xixbR51gXles+5J8VZj8KNxOGhVd1Fzhsy9f65o=; b=7J7JDSegyzx5BPT0qW0GKFih/Xas2R/jDNnymU2FQAbNxVuA/K5yyIWnIc2Y4+DOe1 PQLR61EoLr9B3XWYmdIu03pVTlqWP3S9gwlNq+Ims8Bbyd6mmPt0p17VPtIJoO3pSMkM xthYqdLZVg7of1ADwdPJxPOmaHZ2IkZaaoNWKGgykTfZLGdaORiXvy5nXuYF4S3RoBrY ldM+RUYRb1wPfGUrMM9BdFji3HBvko7qsv9fMaRQhNIvmJQgsSDMUVqnbuD25ZwpdwUF F8OrbCoOhYxTvpfbWMFfArwOpEwHlhwK1+flGjwhQfqzE1pJl7HbPrP3+6vs5Ls7DcE9 vUbg== X-Gm-Message-State: AOAM5336IHNsVSVbqLH0jR7QKP9LTrge+++KVUVusPGnb3zVkEYuk8aI Lj4VP7HC3kN01C1KR8TWO3aMR0v4SnX/GslCyXroiA== X-Google-Smtp-Source: ABdhPJyN1CRH4zeQufyL2aiRVxjIOw7oQZlMDNI1y0PotNLGf10/vB/EOcpFnK+1Bhp6Jhw4s6sfPXvZMX1NoOQ6alI= X-Received: by 2002:a9f:23d0:: with SMTP id 74mr5762756uao.69.1633726153629; Fri, 08 Oct 2021 13:49:13 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Fri, 8 Oct 2021 14:49:02 -0600 Message-ID: Subject: Re: Dell Latitude 7400 - nvme0: Missing interrupt To: Pavel Timofeev Cc: Chuck Tuffli , freebsd-current Content-Type: multipart/alternative; boundary="0000000000000c35c905cddd837c" X-Rspamd-Queue-Id: 4HR0ff3hSMz3sgx X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --0000000000000c35c905cddd837c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Oct 8, 2021 at 2:42 PM Pavel Timofeev wrote: > > > =D1=81=D0=B1, 21 =D0=B0=D0=B2=D0=B3. 2021 =D0=B3. =D0=B2 15:22, Warner Lo= sh : > >> >> >> On Sat, Aug 21, 2021 at 3:06 PM Pavel Timofeev wrote: >> >>> >>> >>> Warner Losh : >>> >>>> >>>> >>>> On Fri, Aug 20, 2021 at 10:42 PM Pavel Timofeev >>>> wrote: >>>> >>>>> Pavel Timofeev : >>>>> >>>>> > >>>>> > Chuck Tuffli : >>>>> > >>>>> >> On Mon, Aug 16, 2021 at 7:43 PM Pavel Timofeev >>>>> wrote: >>>>> >> > >>>>> >> > Hello >>>>> >> > I've got a Dell Latitude 7400 and tried installing the latest >>>>> >> 14.0-CURRENT >>>>> >> > (main-n248636-d20e9e02db3) on it. >>>>> >> > Despite other things the weird one which concerns me is >>>>> >> > nvme0: Missing interrupt >>>>> >> > message I get sometimes on the console. >>>>> >> > It seems like I get it only after the reboot of the laptop, i. e= . >>>>> not >>>>> >> > getting that message if I power cycle the laptop, at least I >>>>> haven't >>>>> >> seen >>>>> >> > them for now in such cases. >>>>> >> > So when the laptop is rebooted I can't even take advantage of >>>>> >> > nvmecontrol(8) quickly. >>>>> >> > Well, it still works, but it takes tens of seconds to return the >>>>> output. >>>>> >> ... >>>>> >> > dmesg when power cycled - >>>>> >> > https://drive.google.com/file/d/1dB27oB1O2CcnZy6DvOOhmFO8SN8V8Sw= J >>>>> >> > dmesg when rebooted - >>>>> >> > https://drive.google.com/file/d/1DsKTMkihp_OmUcirByLaVO4o2mU38Bx= h >>>>> >> >>>>> >> I'm sort of curious about the time stamps for the log messages in >>>>> the >>>>> >> failing case. Something like: >>>>> >> >>>>> >> $ grep "nv\(me\|d\)" /var/log/messages >>>>> >> >>>>> >> --chuck >>>>> >> >>>>> > >>>>> > Well, I can't see timestamps in the verbose boot log. Am I missing >>>>> some >>>>> > configuration for that? >>>>> > >>>>> > $ grep "nv\(me\|d\)" /var/log/messages >>>>> > nvme0: mem >>>>> > 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff a= t >>>>> device >>>>> > 0.0 on pci6 >>>>> > nvme0: attempting to allocate 5 MSI-X vectors (17 supported) >>>>> > nvme0: using IRQs 133-137 for MSI-X >>>>> > nvme0: CapLo: 0x140103ff: MQES 1023, CQR, TO 20 >>>>> > nvme0: CapHi: 0x00000030: DSTRD 0, NSSRS, CSS 1, MPSMIN 0, MPSMAX 0 >>>>> > nvme0: Version: 0x00010300: 1.3 >>>>> > nvme0: Missing interrupt >>>>> > nvme0: Missing interrupt >>>>> > nvme0: Missing interrupt >>>>> > nvme0: Missing interrupt >>>>> > nvme0: Missing interrupt >>>>> > nvme0: Missing interrupt >>>>> > nvme0: Missing interrupt >>>>> > nvme0: Missing interrupt >>>>> > nvme0: Missing interrupt >>>>> > nvme0: Missing interrupt >>>>> > nvme0: Missing interrupt >>>>> > nvme0: Missing interrupt >>>>> > nvd0: NVMe namespace >>>>> > GEOM: new disk nvd0 >>>>> > nvd0: 488386MB (1000215216 512 byte sectors) >>>>> > >>>>> >>>>> >>>>> Ah, sorry, provided wrong output. >>>>> Here is what you requested: >>>>> $ grep "nv\(me\|d\)" /var/log/messages >>>>> Aug 21 04:34:36 nostromo kernel: nvme0: mem >>>>> 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff at >>>>> device >>>>> 0.0 on pci6 >>>>> Aug 21 04:34:36 nostromo kernel: nvme0: attempting to allocate 5 MSI-= X >>>>> vectors (17 supported) >>>>> Aug 21 04:34:36 nostromo kernel: nvme0: using IRQs 133-137 for MSI-X >>>>> Aug 21 04:34:36 nostromo kernel: nvme0: CapLo: 0x140103ff: MQES 1023, >>>>> CQR, >>>>> TO 20 >>>>> Aug 21 04:34:36 nostromo kernel: nvme0: CapHi: 0x00000030: DSTRD 0, >>>>> NSSRS, >>>>> CSS 1, MPSMIN 0, MPSMAX 0 >>>>> Aug 21 04:34:36 nostromo kernel: nvme0: Version: 0x00010300: 1.3 >>>>> Aug 21 04:34:36 nostromo kernel: nvme0: Missing interrupt >>>>> Aug 21 04:34:36 nostromo kernel: nvme0: Missing interrupt >>>>> Aug 21 04:34:36 nostromo kernel: nvme0: Missing interrupt >>>>> Aug 21 04:34:36 nostromo kernel: nvd0: NV= Me >>>>> namespace >>>>> Aug 21 04:34:36 nostromo kernel: GEOM: new disk nvd0 >>>>> Aug 21 04:34:36 nostromo kernel: nvd0: 488386MB (1000215216 512 byte >>>>> sectors) >>>>> Aug 21 04:34:42 nostromo kernel: nvme0: Missing interrupt >>>>> Aug 21 04:35:36 nostromo kernel: nvme0: Missing interrupt >>>>> Aug 21 04:35:50 nostromo kernel: nvme0: Missing interrupt >>>>> >>>> >>>> What happens if you set hw.nvme.use_nvd=3D0 and hw.cam.nda.nvd_compat= =3D1 >>>> in the boot loader and reboot? Same thing except nda where nvd was? Or >>>> does >>>> it work? >>>> >>>> Something weird is going on in the interrupt assignment, I think, but = I >>>> wanted to get any nvd vs nda issues out of the way first. >>>> >>>> Warner >>>> >>> >>> Do you mean kern.cam.nda.nvd_compat instead of hw.cam.nda.nvd_compat? >>> kern.cam.nda.nvd_compat is 1 by default now. >>> >>> So I tried to set hw.nvme.use_nvd to 1 as suggested, but I still see >>> nvme0: Missing interrupt >>> and now also >>> Root mount waiting for: CAM >>> messages besides those >>> >> >> OK. That all makes sense. I'd forgotten that nvd_compat=3D1 by default t= hese >> days. >> >> I'll take a look on monday starting at the differences in interrupt >> assignment that >> are apparent when you cold boot vs reboot. >> >> Thanks for checking... I'd hoped this was a cheap fix, but also didn't >> really >> expect it to be. >> >> Warner >> >> > I've recently upgraded to main-n249974-17f790f49f5 and it got even worse > now. > So clean poweron works as before. > But if rebooted nvme drive refuses to work, while before the code upgrade > it was just complaining about missing interrupts. > > currently dmesg show this: > nvme0: mem > 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff at devi= ce > 0.0 on pci6 > nvd0: NVMe namespace > nvd0: 488386MB (1000215216 512 byte sectors) > nvme0: mem > 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff at devi= ce > 0.0 on pci6 > Why is this showing up twice? Or is everything above this line left over from the first, working boot? > nvme0: RECOVERY_START 9585870784 vs 9367036288 > nvme0: timeout with nothing complete, resetting > nvme0: Resetting controller due to a timeout. > nvme0: RECOVERY_WAITING > nvme0: resetting controller > nvme0: aborting outstanding admin command > nvme0: IDENTIFY (06) sqid:0 cid:15 nsid:0 cdw10:00000001 cdw11:00000000 > nvme0: ABORTED - BY REQUEST (00/07) sqid:0 cid:15 cdw0:0 > nvme0: nvme_identify_controller failed! > nvme0: waiting > Clearly something bad is going on with the drive here... We looked into the completion queues when we didn't get an interrupt and there was nothing complete there.... The only thing I can think of is that this means there's a phase error between the drive and the system. I recently removed a second reset and made it an option NVME_2X_RESET. Can you see if adding 'options NVME_2X_RESET' to your kernel config fixes this? Warner > nvme0: mem > 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff at devi= ce > 0.0 on pci6 > nvme0: RECOVERY_START 9362778467 vs 9361830561 > nvme0: timeout with nothing complete, resetting > nvme0: Resetting controller due to a timeout. > nvme0: RECOVERY_WAITING > nvme0: resetting controller > nvme0: aborting outstanding admin command > nvme0: IDENTIFY (06) sqid:0 cid:15 nsid:0 cdw10:00000001 cdw11:00000000 > nvme0: ABORTED - BY REQUEST (00/07) sqid:0 cid:15 cdw0:0 > nvme0: nvme_identify_controller failed! > nvme0: waiting > > --0000000000000c35c905cddd837c-- From nobody Sat Oct 9 07:46:24 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 5789417E1FE1 for ; Sat, 9 Oct 2021 07:46:43 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp5.goneo.de (smtp5.goneo.de [IPv6:2001:1640:5::8:30]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HRHFF6WsYz3qk1 for ; Sat, 9 Oct 2021 07:46:41 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from hub1.goneo.de (hub1.goneo.de [IPv6:2001:1640:5::8:52]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by smtp5.goneo.de (Postfix) with ESMTPS id B2927103171F for ; Sat, 9 Oct 2021 09:46:34 +0200 (CEST) Received: from hub1.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPS id 4A4F610A75E2 for ; Sat, 9 Oct 2021 09:46:31 +0200 (CEST) Received: from jelly.fritz.box (dynamic-2a01-0c22-a5c8-b300-f963-45d5-5ecb-03a8.c22.pool.telefonica.de [IPv6:2a01:c22:a5c8:b300:f963:45d5:5ecb:3a8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPSA id 1B63110A75DF for ; Sat, 9 Oct 2021 09:46:31 +0200 (CEST) Date: Sat, 9 Oct 2021 09:46:24 +0200 From: FreeBSD User To: freebsd-current@freebsd.org Subject: clang/llvm-tblgen --- ld: error: undefined symbol: setupterm Message-ID: <20211009094624.3f3cacc8@jelly.fritz.box> Organization: FreeBSD in der Heimstatt List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-UID: bba476 X-Rspamd-UID: 82658b X-Rspamd-Queue-Id: 4HRHFF6WsYz3qk1 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd@walstatt-de.de has no SPF policy when checking 2001:1640:5::8:30) smtp.mailfrom=freebsd@walstatt-de.de X-Spamd-Result: default: False [-2.04 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.87)[-0.870]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.97)[-0.967]; 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]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; DMARC_NA(0.00)[walstatt-de.de]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:25394, ipnet:2001:1640::/32, country:DE]; RCVD_TLS_ALL(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[2001:1640:5::8:30:from] X-ThisMailContainsUnwantedMimeParts: N On recent CURRENT (FreeBSD 14.0-CURRENT #2 main-n249971-0525ece3554e: Fri Oct 8 15:17:34 CEST 2021 amd64) building of an 13-STABLE based appliance failed very early in the build process of the 13-STABLE sources as shown below. 13-STABLE is most recent, since the sources are fetched every time the build process is triggered. The framework for the build process is nanoBSD, the same error occurs when building poudriere's jail based upon 13-STABLE from scratch via the FreeBSD native build framework. "Cross building" of 13-STABLE on a CURRENT platform worked in most cases and most time, hopefully this hickup is a solveable problem and it would be nice to have this fixed. What is the reason for the linker fail? Are there any recommenadtions how to "cross build" 13-STABLE on a 14-CURRENT platform in case the approach of mine s not a desireable on? Thanks in advance, Oliver [...] sh /pool/home/ohartmann/Projects/router/router/apu2c4/src/tools/install.sh -s -o root -g wheel -m 555 compile_et /pool/home/ohartmann/Projects/router/router/apu2 c4/world/amd64/ALERICH_13-STABLE_amd64/pool/home/ohartmann/Projects/router/router/apu2c4/src/amd64.amd64/tmp/legacy/usr/bin/compile_et --- _bootstrap-tools-usr.bin/clang/llvm-tblgen --- ld: error: undefined symbol: setupterm >>> referenced by Process.cpp >>> Process.o:(llvm::sys::Process::FileDescriptorHasColors(int)) >>> in archive >>> /pool/home/ohartmann/Projects/router/router/apu2c4/world/amd64/ALERICH_13-STABLE_amd64/pool/home/ohartmann/Projects/router/router/apu2c4/src/amd64.amd64/tmp/obj-tools/lib/clang/libllvmminimal/libllvmminimal.a From nobody Sat Oct 9 09:14:38 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0645517EC4C4 for ; Sat, 9 Oct 2021 09:14:50 +0000 (UTC) (envelope-from olivier@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HRKBx6TW6z4TfS for ; Sat, 9 Oct 2021 09:14:49 +0000 (UTC) (envelope-from olivier@freebsd.org) Received: from mail-ua1-f47.google.com (mail-ua1-f47.google.com [209.85.222.47]) (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: olivier/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id BA4D9DA68 for ; Sat, 9 Oct 2021 09:14:49 +0000 (UTC) (envelope-from olivier@freebsd.org) Received: by mail-ua1-f47.google.com with SMTP id a2so4322552uaq.10 for ; Sat, 09 Oct 2021 02:14:49 -0700 (PDT) X-Gm-Message-State: AOAM532rcas58fYQekfmK7YLnt6Uw9kHh4sOIAcQ3CohEt5PnEUX3qAj yrEc18oq+UO5MKZeMBp55yDDlXuZhwKNS0uwkzM= X-Google-Smtp-Source: ABdhPJzA3BhanUY0dv5qWFJvWhKXrL+s4aJt70p5OSyUN8HGK613foGo+DhZCmN9NtM9ZWWn5hK2FCv8tIzvOEw2TyQ= X-Received: by 2002:a9f:2371:: with SMTP id 104mr7651803uae.80.1633770889244; Sat, 09 Oct 2021 02:14:49 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <20211009094624.3f3cacc8@jelly.fritz.box> In-Reply-To: <20211009094624.3f3cacc8@jelly.fritz.box> From: =?UTF-8?Q?Olivier_Cochard=2DLabb=C3=A9?= Date: Sat, 9 Oct 2021 11:14:38 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: clang/llvm-tblgen --- ld: error: undefined symbol: setupterm To: FreeBSD User Cc: freebsd-current Content-Type: multipart/alternative; boundary="0000000000007f74fe05cde7ed95" X-ThisMailContainsUnwantedMimeParts: Y --0000000000007f74fe05cde7ed95 Content-Type: text/plain; charset="UTF-8" On Sat, Oct 9, 2021 at 9:48 AM FreeBSD User wrote: > On recent CURRENT (FreeBSD 14.0-CURRENT #2 main-n249971-0525ece3554e: > Fri Oct 8 15:17:34 CEST 2021 amd64) building of an 13-STABLE based > appliance failed very early in the build process of the 13-STABLE > sources as shown below. 13-STABLE is most recent, since the sources are > fetched every time the build process is triggered. > > Same problem here with nanobsd too: Building a few weeks old FreeBSD CURRENT nanobsd image (like source from Sept 9) from a more recent dev environment (like CURRENT built Sept 25) is enough to reproduce this problem. Regards, Olivier --0000000000007f74fe05cde7ed95-- From nobody Sat Oct 9 11:37:36 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 08EAD17F79EF for ; Sat, 9 Oct 2021 11:37:49 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HRNMw6lj8z4dl5; Sat, 9 Oct 2021 11:37:48 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:470:7a58:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "R3" (verified OK)) (Authenticated sender: dim) by smtp.freebsd.org (Postfix) with ESMTPSA id 9BE07F409; Sat, 9 Oct 2021 11:37:48 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtpclient.apple (unknown [IPv6:2001:470:7a58:0:2191:2238:625b:d64d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 08CCC4F8E9; Sat, 9 Oct 2021 13:37:46 +0200 (CEST) From: Dimitry Andric Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_71F3AAD4-2AF3-4432-B6A0-F969FB9DA706"; protocol="application/pgp-signature"; micalg=pgp-sha1 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: clang/llvm-tblgen --- ld: error: undefined symbol: setupterm Date: Sat, 9 Oct 2021 13:37:36 +0200 In-Reply-To: <20211009094624.3f3cacc8@jelly.fritz.box> Cc: freebsd-current@freebsd.org To: FreeBSD User References: <20211009094624.3f3cacc8@jelly.fritz.box> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_71F3AAD4-2AF3-4432-B6A0-F969FB9DA706 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 9 Oct 2021, at 09:46, FreeBSD User wrote: >=20 > On recent CURRENT (FreeBSD 14.0-CURRENT #2 main-n249971-0525ece3554e: > Fri Oct 8 15:17:34 CEST 2021 amd64) building of an 13-STABLE based > appliance failed very early in the build process of the 13-STABLE > sources as shown below. 13-STABLE is most recent, since the sources = are > fetched every time the build process is triggered. ... > = /pool/home/ohartmann/Projects/router/router/apu2c4/src/tools/install.sh > -s -o root -g wheel -m 555 compile_et > /pool/home/ohartmann/Projects/router/router/apu2 > = c4/world/amd64/ALERICH_13-STABLE_amd64/pool/home/ohartmann/Projects/router= /router/apu2c4/src/amd64.amd64/tmp/legacy/usr/bin/compile_et > --- _bootstrap-tools-usr.bin/clang/llvm-tblgen --- ld: error: = undefined > symbol: setupterm >>>> referenced by Process.cpp >>>> = Process.o:(llvm::sys::Process::FileDescriptorHasColors(int)) It is complaining about ncurses functions; it seems that even though the = link step gets -lncursesw added, it still is not able to find the = symbol: c++ -O2 -pipe -fno-common = -I/usr/obj/share/dim/src/freebsd/stable-13/amd64.amd64/tmp/obj-tools/lib/c= lang/libllvm -I/share/dim/src/freebsd/stable-13/lib/clang/include = -I/share/dim/src/freebsd/stable-13/contrib/llvm-project/llvm/include = -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS = -DHAVE_VCS_VERSION_INC -DNDEBUG = -DLLVM_DEFAULT_TARGET_TRIPLE=3D\"x86_64-unknown-freebsd13.0\" = -DLLVM_HOST_TRIPLE=3D\"x86_64-unknown-freebsd13.0\" = -DDEFAULT_SYSROOT=3D\"/usr/obj/share/dim/src/freebsd/stable-13/amd64.amd64= /tmp\" -DLLVM_TARGET_ENABLE_X86 = -DLLVM_NATIVE_ASMPARSER=3DLLVMInitializeX86AsmParser = -DLLVM_NATIVE_ASMPRINTER=3DLLVMInitializeX86AsmPrinter = -DLLVM_NATIVE_DISASSEMBLER=3DLLVMInitializeX86Disassembler = -DLLVM_NATIVE_TARGET=3DLLVMInitializeX86Target = -DLLVM_NATIVE_TARGETINFO=3DLLVMInitializeX86TargetInfo = -DLLVM_NATIVE_TARGETMC=3DLLVMInitializeX86TargetMC -ffunction-sections = -fdata-sections -gline-tables-only -Wno-format-zero-length = -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable = -Wno-error=3Dunused-but-set-variable -Wno-tautological-compare = -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function = -Wno-enum-conversion -Wno-unused-local-typedef = -Wno-address-of-packed-member -Wno-switch -Wno-switch-enum = -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments = -I/usr/obj/share/dim/src/freebsd/stable-13/amd64.amd64/tmp/legacy/usr/incl= ude -fno-exceptions -fno-rtti -std=3Dc++14 -stdlib=3Dlibc++ = -Wno-c++11-extensions -Wl,--gc-sections -static = -L/usr/obj/share/dim/src/freebsd/stable-13/amd64.amd64/tmp/legacy/usr/lib = -o llvm-tblgen.full AsmMatcherEmitter.o AsmWriterEmitter.o = AsmWriterInst.o Attributes.o CTagsEmitter.o CallingConvEmitter.o = CodeEmitterGen.o CodeGenDAGPatterns.o CodeGenHwModes.o = CodeGenInstruction.o CodeGenMapTable.o CodeGenRegisters.o = CodeGenSchedule.o CodeGenTarget.o DAGISelEmitter.o DAGISelMatcher.o = DAGISelMatcherEmitter.o DAGISelMatcherGen.o DAGISelMatcherOpt.o = DFAEmitter.o DFAPacketizerEmitter.o DirectiveEmitter.o = DisassemblerEmitter.o ExegesisEmitter.o FastISelEmitter.o = FixedLenDecoderEmitter.o GICombinerEmitter.o GlobalISel/CodeExpander.o = GlobalISel/GIMatchDag.o GlobalISel/GIMatchDagEdge.o = GlobalISel/GIMatchDagInstr.o GlobalISel/GIMatchDagOperands.o = GlobalISel/GIMatchDagPredicate.o = GlobalISel/GIMatchDagPredicateDependencyEdge.o GlobalISel/GIMatchTree.o = GlobalISelEmitter.o InfoByHwMode.o InstrDocsEmitter.o InstrInfoEmitter.o = IntrinsicEmitter.o OptEmitter.o OptParserEmitter.o OptRSTEmitter.o = PredicateExpander.o PseudoLoweringEmitter.o RISCVCompressInstEmitter.o = RegisterBankEmitter.o RegisterInfoEmitter.o SDNodeProperties.o = SearchableTableEmitter.o SubtargetEmitter.o SubtargetFeatureInfo.o = TableGen.o Types.o WebAssemblyDisassemblerEmitter.o = X86DisassemblerTables.o X86EVEX2VEXTablesEmitter.o = X86FoldTablesEmitter.o X86ModRMFilters.o X86RecognizableInstr.o = /usr/obj/share/dim/src/freebsd/stable-13/amd64.amd64/tmp/obj-tools/lib/cla= ng/libllvmminimal/libllvmminimal.a = -L/usr/obj/share/dim/src/freebsd/stable-13/amd64.amd64/tmp/obj-tools/lib/l= ibexecinfo -lexecinfo = -L/usr/obj/share/dim/src/freebsd/stable-13/amd64.amd64/tmp/obj-tools/lib/l= ibelf -lelf = -L/usr/obj/share/dim/src/freebsd/stable-13/amd64.amd64/tmp/obj-tools/lib/n= curses/ncurses -lncursesw = -L/usr/obj/share/dim/src/freebsd/stable-13/amd64.amd64/tmp/obj-tools/lib/l= ibthr -lpthread -legacy ld: error: undefined symbol: setupterm >>> referenced by Process.inc:336 = (/share/dim/src/freebsd/stable-13/contrib/llvm-project/llvm/lib/Support/Un= ix/Process.inc:336) >>> = Process.o:(llvm::sys::Process::FileDescriptorHasColors(int)) in archive = /usr/obj/share/dim/src/freebsd/stable-13/amd64.amd64/tmp/obj-tools/lib/cla= ng/libllvmminimal/libllvmminimal.a ld: error: undefined symbol: tigetnum >>> referenced by Process.inc:354 = (/share/dim/src/freebsd/stable-13/contrib/llvm-project/llvm/lib/Support/Un= ix/Process.inc:354) >>> = Process.o:(llvm::sys::Process::FileDescriptorHasColors(int)) in archive = /usr/obj/share/dim/src/freebsd/stable-13/amd64.amd64/tmp/obj-tools/lib/cla= ng/libllvmminimal/libllvmminimal.a ld: error: undefined symbol: set_curterm >>> referenced by Process.inc:358 = (/share/dim/src/freebsd/stable-13/contrib/llvm-project/llvm/lib/Support/Un= ix/Process.inc:358) >>> = Process.o:(llvm::sys::Process::FileDescriptorHasColors(int)) in archive = /usr/obj/share/dim/src/freebsd/stable-13/amd64.amd64/tmp/obj-tools/lib/cla= ng/libllvmminimal/libllvmminimal.a ld: error: undefined symbol: del_curterm >>> referenced by Process.inc:359 = (/share/dim/src/freebsd/stable-13/contrib/llvm-project/llvm/lib/Support/Un= ix/Process.inc:359) >>> = Process.o:(llvm::sys::Process::FileDescriptorHasColors(int)) in archive = /usr/obj/share/dim/src/freebsd/stable-13/amd64.amd64/tmp/obj-tools/lib/cla= ng/libllvmminimal/libllvmminimal.a c++: error: linker command failed with exit code 1 (use -v to see = invocation) Probably it is due to the preceding = -L/usr/obj/share/dim/src/freebsd/stable-13/amd64.amd64/tmp/obj-tools/lib/n= curses/ncurses option, as that directory (and the supposed libncursesw.a = there) does not exist yet at the bootstrap-tools stage. I am not sure if it should use that library path at all, though. It = should really link to the *host* ncursesw library instead. -Dimitry --Apple-Mail=_71F3AAD4-2AF3-4432-B6A0-F969FB9DA706 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCYWF/AAAKCRCwXqMKLiCW o/K7AKD+Tl8KFArY9RhlA+FLZQZFizXPCQCfYjws96yCnJJKe9q+REFpfITpM6s= =vph4 -----END PGP SIGNATURE----- --Apple-Mail=_71F3AAD4-2AF3-4432-B6A0-F969FB9DA706-- From nobody Sat Oct 9 11:58:37 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 79CC012B29CC for ; Sat, 9 Oct 2021 11:58:46 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HRNr62y8Bz4gn0; Sat, 9 Oct 2021 11:58:46 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "R3" (verified OK)) (Authenticated sender: dim) by smtp.freebsd.org (Postfix) with ESMTPSA id 2B448F53B; Sat, 9 Oct 2021 11:58:46 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtpclient.apple (unknown [IPv6:2001:470:7a58:0:2191:2238:625b:d64d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id F00654F7EA; Sat, 9 Oct 2021 13:58:43 +0200 (CEST) From: Dimitry Andric Message-Id: <2FCA108B-29E1-48EA-A8C7-BC621CC6F963@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_A1DC35F2-CC15-4819-9096-6935A38F0619"; protocol="application/pgp-signature"; micalg=pgp-sha1 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: clang/llvm-tblgen --- ld: error: undefined symbol: setupterm Date: Sat, 9 Oct 2021 13:58:37 +0200 In-Reply-To: Cc: FreeBSD CURRENT , Baptiste Daroussin To: FreeBSD User References: <20211009094624.3f3cacc8@jelly.fritz.box> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_A1DC35F2-CC15-4819-9096-6935A38F0619 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 9 Oct 2021, at 13:37, Dimitry Andric wrote: >=20 > On 9 Oct 2021, at 09:46, FreeBSD User wrote: >>=20 >> On recent CURRENT (FreeBSD 14.0-CURRENT #2 main-n249971-0525ece3554e: >> Fri Oct 8 15:17:34 CEST 2021 amd64) building of an 13-STABLE based >> appliance failed very early in the build process of the 13-STABLE >> sources as shown below. 13-STABLE is most recent, since the sources = are >> fetched every time the build process is triggered. > ... >> = /pool/home/ohartmann/Projects/router/router/apu2c4/src/tools/install.sh >> -s -o root -g wheel -m 555 compile_et >> /pool/home/ohartmann/Projects/router/router/apu2 >> = c4/world/amd64/ALERICH_13-STABLE_amd64/pool/home/ohartmann/Projects/router= /router/apu2c4/src/amd64.amd64/tmp/legacy/usr/bin/compile_et >> --- _bootstrap-tools-usr.bin/clang/llvm-tblgen --- ld: error: = undefined >> symbol: setupterm >>>>> referenced by Process.cpp >>>>> = Process.o:(llvm::sys::Process::FileDescriptorHasColors(int)) >=20 > It is complaining about ncurses functions; it seems that even though = the link step gets -lncursesw added, it still is not able to find the = symbol: Okay, this is because recently on -CURRENT, libtinfow got split off from libncursesw: https://cgit.freebsd.org/src/commit/?id=3D396851c20aebd This affects such cross-builds obviously, and manually adding -ltinfow to the link command line makes it link correctly. However, the 396851c20aebd commit is probably not suitable for MFC'ing to stable/13. Maybe we need to put some kind of kludge in share/mk/src.libnames.mk for this, or in the top-level Makefile.inc1? Baptiste, any ideas? :) -Dimitry --Apple-Mail=_A1DC35F2-CC15-4819-9096-6935A38F0619 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCYWGD7QAKCRCwXqMKLiCW oxoZAJ9GdUjretIh8ERo/RVmVEAz1aXFgQCgghcd6Q4pomrK1aykQ5CfJk8FOKo= =unDS -----END PGP SIGNATURE----- --Apple-Mail=_A1DC35F2-CC15-4819-9096-6935A38F0619-- From nobody Sat Oct 9 12:13:33 2021 X-Original-To: current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B893512B44E0; Sat, 9 Oct 2021 12:13:43 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from woozle.rinet.ru (woozle.rinet.ru [195.54.192.68]) (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 4HRP9L1dqXz4jpk; Sat, 9 Oct 2021 12:13:42 +0000 (UTC) (envelope-from marck@rinet.ru) Received: from localhost (localhost [127.0.0.1]) by woozle.rinet.ru (8.14.5/8.14.5) with ESMTP id 199CDXOP012649; Sat, 9 Oct 2021 15:13:33 +0300 (MSK) (envelope-from marck@rinet.ru) Date: Sat, 9 Oct 2021 15:13:33 +0300 (MSK) From: Dmitry Morozovsky To: Hans Ottevanger cc: Baptiste Daroussin , current@FreeBSD.org, arch@FreeBSD.org Subject: Re: [HEADSUP] making /bin/sh the default shell for root In-Reply-To: <97ebc390-a19e-3203-7016-ce541796eb18@beastielabs.net> Message-ID: References: <20210922083645.4vnoajyvwq6wfhdf@aniel.nours.eu> <97ebc390-a19e-3203-7016-ce541796eb18@beastielabs.net> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) X-NCC-RegID: ru.rinet X-OpenPGP-Key-ID: 6B691B03 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (woozle.rinet.ru [0.0.0.0]); Sat, 09 Oct 2021 15:13:33 +0300 (MSK) X-Rspamd-Queue-Id: 4HRP9L1dqXz4jpk X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=rinet.ru; spf=pass (mx1.freebsd.org: domain of marck@rinet.ru designates 195.54.192.68 as permitted sender) smtp.mailfrom=marck@rinet.ru X-Spamd-Result: default: False [-2.88 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FREEFALL_USER(0.00)[marck]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:195.54.192.68]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; NEURAL_HAM_SHORT(-0.08)[-0.077]; DMARC_POLICY_ALLOW(-0.50)[rinet.ru,none]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:8331, ipnet:195.54.192.0/19, country:RU]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N On Thu, 23 Sep 2021, Hans Ottevanger wrote: [snip] > While there, you could change "Charlie &" in the gecos field to something more > sensible, e.g. just "Superuser". I know Charlie is there since 4.2BSD, but the > reference to a long forgotten baseball player is probably lost by now. Also, a > lot of explanation is often needed when users receive (automated) emails from > Charlie Root. FWIW, my deployment route includes changind this to "`hostname-s` &" which helps much when digging into root-robots mail folder RE: history, "!cmd" and "!?param" would be great if implemented @sh [snip] -- Sincerely, D.Marck [DM5020, MCK-RIPE, DM3-RIPN] [ FreeBSD committer: marck@FreeBSD.org ] --------------------------------------------------------------------------- *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- woozle@woozle.net *** --------------------------------------------------------------------------- From nobody Sat Oct 9 13:40:52 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E694312D4DF3 for ; Sat, 9 Oct 2021 13:41:05 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HRR69620Bz4plY for ; Sat, 9 Oct 2021 13:41:05 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ua1-x934.google.com with SMTP id f3so5187216uap.6 for ; Sat, 09 Oct 2021 06:41:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=l4zg5xJb4FBTGZ6GsnGjP1oe3PEG2uST0E9hWUt1+Do=; b=pKNrCFJ+rPKikjz7+dIcn1U8DUjTjJ/jxAeIZgRBxB0vx9DZaQMd1FuA+e+JFT5lJi FybD/2rp/ijLs7xWoztXJB3n5FnWtxi7AqUW6ZCeWo3N8AAoL5knoE76kNSUpYmzUt28 Mju3T2sQ0eitiUInC9ECF8ixQzvnJNIoFF3mdxQA1fO5+0KH/JljNwI9et67RFVCxn9g cbYKhxO2+bYKEzaBfoNgcIcXi9RrFhmi0BEhCuuQuGUlK98p2zSbgvvoixA+QSokBYiK LxYTThzv8KLuZuKcRB+UkXA1zstrwZo6secOIuS1wfvhzKs0zOSB+zD5ELM9ZBZHA+0n 4HMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=l4zg5xJb4FBTGZ6GsnGjP1oe3PEG2uST0E9hWUt1+Do=; b=lEQgiqo/xO5/ALoyRpUWTvN40W/Z94wNm1YRcEmEMyzEpthP1+gWvHdzBDDjewort8 lfNKTCa3BkQnEXr2FJPJYM4/vVLEZ+Xqjvhu7EEyCTzvmq8UqyiKxkCK8h1/vVWR7KHb WHBsqPojqcK0MBwPqTenR9tZtglA9BRmBqxZnDrAWhaDFVBVVM87DjBCh2J9g1Tq7W1G WxmY0/q13q2QVLY2OBYGJ9UiFjhyo7jGekgVinnu/ZPhTFt5h1bCYAg4TZ9fxHK30Gph OoXyElppRQnMgeFpWar7dF6cKF1Gn0bjxeCVFX6d0jyx9xEDqqT/3qxI4Nbh+/1xAClA NfUA== X-Gm-Message-State: AOAM532vyYaccAFB54yw136upJnLgu+BO7/0JcLhQvEWAikSR8pcQ+fV s126Nw3K9eQtNAV5woOJYPXfeJjqhUWpwlhZyLIVyg== X-Google-Smtp-Source: ABdhPJyLZ8fv6zxvJoGbhR7Jw8E2GyE4qD5bRRT3r1oykkQMjIFqObK08Xjp5K4a+FXe5ukAgGtXPbaX7RhyFmGWOio= X-Received: by 2002:ab0:6c56:: with SMTP id q22mr8649659uas.39.1633786865085; Sat, 09 Oct 2021 06:41:05 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <20211009094624.3f3cacc8@jelly.fritz.box> <2FCA108B-29E1-48EA-A8C7-BC621CC6F963@FreeBSD.org> In-Reply-To: <2FCA108B-29E1-48EA-A8C7-BC621CC6F963@FreeBSD.org> From: Warner Losh Date: Sat, 9 Oct 2021 07:40:52 -0600 Message-ID: Subject: Re: clang/llvm-tblgen --- ld: error: undefined symbol: setupterm To: Dimitry Andric Cc: FreeBSD User , FreeBSD CURRENT , Baptiste Daroussin Content-Type: multipart/alternative; boundary="000000000000bb80d605cdeba55b" X-Rspamd-Queue-Id: 4HRR69620Bz4plY X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --000000000000bb80d605cdeba55b Content-Type: text/plain; charset="UTF-8" On Sat, Oct 9, 2021, 5:59 AM Dimitry Andric wrote: > On 9 Oct 2021, at 13:37, Dimitry Andric wrote: > > > > On 9 Oct 2021, at 09:46, FreeBSD User wrote: > >> > >> On recent CURRENT (FreeBSD 14.0-CURRENT #2 main-n249971-0525ece3554e: > >> Fri Oct 8 15:17:34 CEST 2021 amd64) building of an 13-STABLE based > >> appliance failed very early in the build process of the 13-STABLE > >> sources as shown below. 13-STABLE is most recent, since the sources are > >> fetched every time the build process is triggered. > > ... > >> /pool/home/ohartmann/Projects/router/router/apu2c4/src/tools/install.sh > >> -s -o root -g wheel -m 555 compile_et > >> /pool/home/ohartmann/Projects/router/router/apu2 > >> > c4/world/amd64/ALERICH_13-STABLE_amd64/pool/home/ohartmann/Projects/router/router/apu2c4/src/amd64.amd64/tmp/legacy/usr/bin/compile_et > >> --- _bootstrap-tools-usr.bin/clang/llvm-tblgen --- ld: error: undefined > >> symbol: setupterm > >>>>> referenced by Process.cpp > >>>>> > Process.o:(llvm::sys::Process::FileDescriptorHasColors(int)) > > > > It is complaining about ncurses functions; it seems that even though the > link step gets -lncursesw added, it still is not able to find the symbol: > > Okay, this is because recently on -CURRENT, libtinfow got split off from > libncursesw: https://cgit.freebsd.org/src/commit/?id=396851c20aebd > > This affects such cross-builds obviously, and manually adding -ltinfow > to the link command line makes it link correctly. > > However, the 396851c20aebd commit is probably not suitable for MFC'ing > to stable/13. Maybe we need to put some kind of kludge in > share/mk/src.libnames.mk for this, or in the top-level Makefile.inc1? > > Baptiste, any ideas? :) > Add setupterm() to libegacy as a nop. Warner -Dimitry > > --000000000000bb80d605cdeba55b-- From nobody Sat Oct 9 14:18:52 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 2324212D9F3B for ; Sat, 9 Oct 2021 14:18:55 +0000 (UTC) (envelope-from felix@palmen-it.de) Received: from stef.palmen-it.de (stef.palmen-it.de [IPv6:2001:470:1f0b:bbb:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HRRxp41sNz4vVb for ; Sat, 9 Oct 2021 14:18:54 +0000 (UTC) (envelope-from felix@palmen-it.de) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=palmen-it.de; s=20200414; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:To:From:Date:Sender:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=skDwtCItV1VMV6CnejAPFuCsTg64VpqfKwZuN61iPSg=; b=OYMW2UgKsfe/EkdeLZMtM/4Sjg 0+QgtZRBMeNhinj/rfMMIqJxaAJMiI5qE7OD74UYQBNr8fWPKxXQWx6jQsnnHiZUjO6foo8kHS1O/ JCOeBBCUaF7E3xk1WccS6fLRmxwDIJypdudgtFtPszgR7nulBalf0nEb5TuU4gJO5lCpKfH12pwRe l6q7IFBPou0WIHymktLi5XOexn39omV2SQJZOzlUIBzaUJ6dDDxDwaKLrsMJnPbpJVQWvE1VAJYoZ c0gkPLgBibUByGfSZCX+oJsALdUDPi+RzDrescE96mbFZOisHuxM3roKsW0gPQIUnAz66S7LdsAme yaNcsCTQ==; Received: from [192.168.71.101] (helo=mail.home.palmen-it.de) by stef.palmen-it.de with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mZDBd-002nEg-C9 for freebsd-current@freebsd.org; Sat, 09 Oct 2021 16:18:53 +0200 Received: from nexus.home.palmen-it.de ([192.168.99.2]) by mail.home.palmen-it.de with esmtpsa (TLS1.3) tls TLS_CHACHA20_POLY1305_SHA256 (Exim 4.94.2 (FreeBSD)) (envelope-from ) id 1mZDBc-000Kh7-V4 for freebsd-current@freebsd.org; Sat, 09 Oct 2021 14:18:53 +0000 Date: Sat, 9 Oct 2021 16:18:52 +0200 From: Felix Palmen To: freebsd-current@freebsd.org Subject: Re: Writing large build logs to NFS extremely slow? Message-ID: <20211009141852.3cmjh7tysnehum7b@nexus.home.palmen-it.de> Mail-Followup-To: freebsd-current@freebsd.org X-Face: /1K@t"h.}e~pR@]c7HorQ!T`F^RJCa'BCr#e>IKA{>C/9OTGB4|xh"y2{?1Z5M i2w"AH^pN_LlHR^{+f',_Np~;.B;!M/bL}*qk]p5*r7F5vW};{:@4u5S?T&f0$7BJ-71Q5SV]:v$`5 A0[DZ:=?S52x8HJ~5@^P_\T@MsjG{R( Organization: palmen-it.de References: <20211007021643.bwglyvrswk2nm3fl@nexus.home.palmen-it.de> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="l4ok3kzphdxr5uz6" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20210205 X-Rspamd-Queue-Id: 4HRRxp41sNz4vVb X-Spamd-Bar: ------- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=palmen-it.de header.s=20200414 header.b=OYMW2UgK; dmarc=pass (policy=none) header.from=palmen-it.de; spf=pass (mx1.freebsd.org: domain of felix@palmen-it.de designates 2001:470:1f0b:bbb:1::1 as permitted sender) smtp.mailfrom=felix@palmen-it.de X-Spamd-Result: default: False [-7.80 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2001:470:1f0b:bbb:1::1:c]; TO_DN_NONE(0.00)[]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[palmen-it.de:+]; RCVD_IN_DNSWL_MED(-0.20)[2001:470:1f0b:bbb:1::1:from]; DMARC_POLICY_ALLOW(-0.50)[palmen-it.de,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[palmen-it.de:s=20200414]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_MED(-2.00)[palmen-it.de:dkim]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --l4ok3kzphdxr5uz6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Mehmet Erol Sanliturk [20211007 10:42]: > The problem is caused mainly by NFS definition parameters . >=20 > If you study NFS definition parameters one by one , I think you will be > able to find which one is effective . >=20 > My opinion is the one setting is "write directly to disk" , i.e. , "do not > use the cache" . >=20 > In the "write directly to disk" case , without completion of a write , t= he > computer in use is waiting for completion of previous write operation > before writing a new record . This is useful in case of abrupt program > terminations because every record is written into the disk file , by > consuming more time . Well this is kind of what I assume might be the problem. Could anyone give me a hint what configuration to change on FreeBSD? --=20 Dipl.-Inform. Felix Palmen ,.//.......... {web} http://palmen-it.de {jabber} [see email] ,//palmen-it.de {pgp public key} http://palmen-it.de/pub.txt // """"""""""" {pgp fingerprint} A891 3D55 5F2E 3A74 3965 B997 3EF2 8B0A BC02 DA2A --l4ok3kzphdxr5uz6 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEqJE9VV8uOnQ5ZbmXPvKLCrwC2ioFAmFhpMwACgkQPvKLCrwC 2iqe8QgAvSJLhLnEBA85H3FRXee2ziQ0gG0/NfeG1YKrC45qnDmHR4nhfwZuBoYd 5q/GeLVB5+bv8Y1oTtNXdeZV+zmWxVQ/e0aLG5sMBCbBtv4f5GgXE6qBX38iuUHS i9ThobuhhsWLZx9JW06fGh+tY+GiqM5jb1UN/WAGdFuA9gzyzJxfUCDLTcvJqzch m6cHKidMUYoqeLPEh6wkJHJ60e94fGouM3ntGQJPN2RVtPovxKhjeYqXiNELsoKX cgREj/Ee+bweZU8vvrMlHIZNTKSBElOHE0nPpZ7sztbdC/RzdJB1sBLkcxFFTbut AattY9QLwabzTbUrUj48i6SS+oM//A== =A4ok -----END PGP SIGNATURE----- --l4ok3kzphdxr5uz6-- From nobody Sat Oct 9 14:44:22 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id DBBF412DE7E5 for ; Sat, 9 Oct 2021 14:44:34 +0000 (UTC) (envelope-from timp87@gmail.com) Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HRSWQ5Wvcz3GF8 for ; Sat, 9 Oct 2021 14:44:34 +0000 (UTC) (envelope-from timp87@gmail.com) Received: by mail-ed1-x52c.google.com with SMTP id p13so48293903edw.0 for ; Sat, 09 Oct 2021 07:44:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4HYOoyyGiwLpKQmKjMGSU3LKG6jFXMM4PHeTjSbv+PE=; b=M5BFqCKXVkqkl4lHCuUTMmKbdaIF8EHMO7l8FuQFA/ofHqw2bOhJYrlVP8GNvOwnHO xXmYF2snQi5eEcV9DPiGx02B9XQruHnRjC5SH2zCP98isrneHpQ/zo5LtzGFbfbApHJK zgm6JDT629HAaBoUKhj3osVrhnPepKjy4S7mhQ3doUTyDUl1GKmTJ76ZBookgQr+Hiqo MD1Ycrla3xM0t/kCDtekIevCZAreDMbqkdb/hembrvKGDGXL+7cLSO6yE3xdzu5mWhKH 1uiU/aIYngime8ckROI+iRE65iAAV2/mK3viydnOc33vXgrZKcWqIto0+SzNX8bDXqFP ejxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4HYOoyyGiwLpKQmKjMGSU3LKG6jFXMM4PHeTjSbv+PE=; b=UxHz7T+wb8dG9ZaTHkZy4GV1utsgOdhWk+oF95XDn0ql7k3D0osQM5hJFylv2c9ED3 BZh5L25qwk6lb/769/p8iG/xgeqSjJHiUZ0/0EPzoEKZvB9Z8uA+85yPVxW7VwdE97Cj /0qs7B6S3WREVHQXc9/b72WS+maqlZd7WCFIs/LoW64QbzDqPOyQQXTby52SVI3t2t8r 3f3aDnm59uSyBHdN5Xn6/sfQowBjEmsEE9xIzwkoA7yPtTkbTWMthrk8VniU15MY4oCu itip9Tg9oHpHOVdacjTnfQMDV4D7ON9qHMPsUuJpviwMTaffxthwxftn+Rf41vRB3WQm 6hpA== X-Gm-Message-State: AOAM531I7OIoA9iCmglEhjGNwpGxTjoVkJetwqWoLieYFSut7QUkA8r+ NrxwN4bOeBMaekeSygk+xPNuW1wwf048kybW348= X-Google-Smtp-Source: ABdhPJwjz2kIquXMfCvTzzVtxMtIrNQW0sZKJzdk1APrAW7/xdOhxfispsZJbMyj33tM0uXnxelpG1RzoRHZpHhK8F4= X-Received: by 2002:a17:906:2506:: with SMTP id i6mr12032476ejb.186.1633790673446; Sat, 09 Oct 2021 07:44:33 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Pavel Timofeev Date: Sat, 9 Oct 2021 08:44:22 -0600 Message-ID: Subject: Re: Dell Latitude 7400 - nvme0: Missing interrupt To: Warner Losh Cc: Chuck Tuffli , freebsd-current Content-Type: multipart/alternative; boundary="000000000000ba6db705cdec8812" X-Rspamd-Queue-Id: 4HRSWQ5Wvcz3GF8 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --000000000000ba6db705cdec8812 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =D0=BF=D1=82, 8 =D0=BE=D0=BA=D1=82. 2021 =D0=B3. =D0=B2 14:49, Warner Losh = : > > > On Fri, Oct 8, 2021 at 2:42 PM Pavel Timofeev wrote: > >> >> >> =D1=81=D0=B1, 21 =D0=B0=D0=B2=D0=B3. 2021 =D0=B3. =D0=B2 15:22, Warner L= osh : >> >>> >>> >>> On Sat, Aug 21, 2021 at 3:06 PM Pavel Timofeev wrote= : >>> >>>> >>>> >>>> Warner Losh : >>>> >>>>> >>>>> >>>>> On Fri, Aug 20, 2021 at 10:42 PM Pavel Timofeev >>>>> wrote: >>>>> >>>>>> Pavel Timofeev : >>>>>> >>>>>> > >>>>>> > Chuck Tuffli : >>>>>> > >>>>>> >> On Mon, Aug 16, 2021 at 7:43 PM Pavel Timofeev >>>>>> wrote: >>>>>> >> > >>>>>> >> > Hello >>>>>> >> > I've got a Dell Latitude 7400 and tried installing the latest >>>>>> >> 14.0-CURRENT >>>>>> >> > (main-n248636-d20e9e02db3) on it. >>>>>> >> > Despite other things the weird one which concerns me is >>>>>> >> > nvme0: Missing interrupt >>>>>> >> > message I get sometimes on the console. >>>>>> >> > It seems like I get it only after the reboot of the laptop, i. >>>>>> e. not >>>>>> >> > getting that message if I power cycle the laptop, at least I >>>>>> haven't >>>>>> >> seen >>>>>> >> > them for now in such cases. >>>>>> >> > So when the laptop is rebooted I can't even take advantage of >>>>>> >> > nvmecontrol(8) quickly. >>>>>> >> > Well, it still works, but it takes tens of seconds to return th= e >>>>>> output. >>>>>> >> ... >>>>>> >> > dmesg when power cycled - >>>>>> >> > >>>>>> https://drive.google.com/file/d/1dB27oB1O2CcnZy6DvOOhmFO8SN8V8SwJ >>>>>> >> > dmesg when rebooted - >>>>>> >> > >>>>>> https://drive.google.com/file/d/1DsKTMkihp_OmUcirByLaVO4o2mU38Bxh >>>>>> >> >>>>>> >> I'm sort of curious about the time stamps for the log messages in >>>>>> the >>>>>> >> failing case. Something like: >>>>>> >> >>>>>> >> $ grep "nv\(me\|d\)" /var/log/messages >>>>>> >> >>>>>> >> --chuck >>>>>> >> >>>>>> > >>>>>> > Well, I can't see timestamps in the verbose boot log. Am I missing >>>>>> some >>>>>> > configuration for that? >>>>>> > >>>>>> > $ grep "nv\(me\|d\)" /var/log/messages >>>>>> > nvme0: mem >>>>>> > 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff >>>>>> at device >>>>>> > 0.0 on pci6 >>>>>> > nvme0: attempting to allocate 5 MSI-X vectors (17 supported) >>>>>> > nvme0: using IRQs 133-137 for MSI-X >>>>>> > nvme0: CapLo: 0x140103ff: MQES 1023, CQR, TO 20 >>>>>> > nvme0: CapHi: 0x00000030: DSTRD 0, NSSRS, CSS 1, MPSMIN 0, MPSMAX = 0 >>>>>> > nvme0: Version: 0x00010300: 1.3 >>>>>> > nvme0: Missing interrupt >>>>>> > nvme0: Missing interrupt >>>>>> > nvme0: Missing interrupt >>>>>> > nvme0: Missing interrupt >>>>>> > nvme0: Missing interrupt >>>>>> > nvme0: Missing interrupt >>>>>> > nvme0: Missing interrupt >>>>>> > nvme0: Missing interrupt >>>>>> > nvme0: Missing interrupt >>>>>> > nvme0: Missing interrupt >>>>>> > nvme0: Missing interrupt >>>>>> > nvme0: Missing interrupt >>>>>> > nvd0: NVMe namespace >>>>>> > GEOM: new disk nvd0 >>>>>> > nvd0: 488386MB (1000215216 512 byte sectors) >>>>>> > >>>>>> >>>>>> >>>>>> Ah, sorry, provided wrong output. >>>>>> Here is what you requested: >>>>>> $ grep "nv\(me\|d\)" /var/log/messages >>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: mem >>>>>> 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff at >>>>>> device >>>>>> 0.0 on pci6 >>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: attempting to allocate 5 MSI= -X >>>>>> vectors (17 supported) >>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: using IRQs 133-137 for MSI-X >>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: CapLo: 0x140103ff: MQES 1023= , >>>>>> CQR, >>>>>> TO 20 >>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: CapHi: 0x00000030: DSTRD 0, >>>>>> NSSRS, >>>>>> CSS 1, MPSMIN 0, MPSMAX 0 >>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: Version: 0x00010300: 1.3 >>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: Missing interrupt >>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: Missing interrupt >>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: Missing interrupt >>>>>> Aug 21 04:34:36 nostromo kernel: nvd0: >>>>>> NVMe >>>>>> namespace >>>>>> Aug 21 04:34:36 nostromo kernel: GEOM: new disk nvd0 >>>>>> Aug 21 04:34:36 nostromo kernel: nvd0: 488386MB (1000215216 512 byte >>>>>> sectors) >>>>>> Aug 21 04:34:42 nostromo kernel: nvme0: Missing interrupt >>>>>> Aug 21 04:35:36 nostromo kernel: nvme0: Missing interrupt >>>>>> Aug 21 04:35:50 nostromo kernel: nvme0: Missing interrupt >>>>>> >>>>> >>>>> What happens if you set hw.nvme.use_nvd=3D0 and hw.cam.nda.nvd_compat= =3D1 >>>>> in the boot loader and reboot? Same thing except nda where nvd was? O= r >>>>> does >>>>> it work? >>>>> >>>>> Something weird is going on in the interrupt assignment, I think, but= I >>>>> wanted to get any nvd vs nda issues out of the way first. >>>>> >>>>> Warner >>>>> >>>> >>>> Do you mean kern.cam.nda.nvd_compat instead of hw.cam.nda.nvd_compat? >>>> kern.cam.nda.nvd_compat is 1 by default now. >>>> >>>> So I tried to set hw.nvme.use_nvd to 1 as suggested, but I still see >>>> nvme0: Missing interrupt >>>> and now also >>>> Root mount waiting for: CAM >>>> messages besides those >>>> >>> >>> OK. That all makes sense. I'd forgotten that nvd_compat=3D1 by default >>> these >>> days. >>> >>> I'll take a look on monday starting at the differences in interrupt >>> assignment that >>> are apparent when you cold boot vs reboot. >>> >>> Thanks for checking... I'd hoped this was a cheap fix, but also didn't >>> really >>> expect it to be. >>> >>> Warner >>> >>> >> I've recently upgraded to main-n249974-17f790f49f5 and it got even worse >> now. >> So clean poweron works as before. >> But if rebooted nvme drive refuses to work, while before the code upgrad= e >> it was just complaining about missing interrupts. >> >> currently dmesg show this: >> nvme0: mem >> 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff at dev= ice >> 0.0 on pci6 >> nvd0: NVMe namespace >> nvd0: 488386MB (1000215216 512 byte sectors) >> nvme0: mem >> 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff at dev= ice >> 0.0 on pci6 >> > > Why is this showing up twice? Or is everything above this line left over > from the first, working boot? > > >> nvme0: RECOVERY_START 9585870784 vs 9367036288 >> nvme0: timeout with nothing complete, resetting >> nvme0: Resetting controller due to a timeout. >> nvme0: RECOVERY_WAITING >> nvme0: resetting controller >> nvme0: aborting outstanding admin command >> nvme0: IDENTIFY (06) sqid:0 cid:15 nsid:0 cdw10:00000001 cdw11:00000000 >> nvme0: ABORTED - BY REQUEST (00/07) sqid:0 cid:15 cdw0:0 >> nvme0: nvme_identify_controller failed! >> nvme0: waiting >> > > Clearly something bad is going on with the drive here... We looked into > the completion queues when we didn't get an interrupt and there was nothi= ng > complete there.... > > The only thing I can think of is that this means there's a phase error > between the drive and the system. I recently removed a second reset and > made it an option NVME_2X_RESET. Can you see if adding > 'options NVME_2X_RESET' to your kernel config fixes this? > > Warner > > >> nvme0: mem >> 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff at dev= ice >> 0.0 on pci6 >> nvme0: RECOVERY_START 9362778467 vs 9361830561 >> nvme0: timeout with nothing complete, resetting >> nvme0: Resetting controller due to a timeout. >> nvme0: RECOVERY_WAITING >> nvme0: resetting controller >> nvme0: aborting outstanding admin command >> nvme0: IDENTIFY (06) sqid:0 cid:15 nsid:0 cdw10:00000001 cdw11:00000000 >> nvme0: ABORTED - BY REQUEST (00/07) sqid:0 cid:15 cdw0:0 >> nvme0: nvme_identify_controller failed! >> nvme0: waiting >> >> Sorry, it's showing twice due to multiple reboots. For one boot it's like: nvme0: mem 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff at device 0.0 on pci6 nvme0: RECOVERY_START 9633303481 vs 9365971423 nvme0: timeout with nothing complete, resetting nvme0: Resetting controller due to a timeout. nvme0: RECOVERY_WAITING nvme0: resetting controller nvme0: aborting outstanding admin command nvme0: IDENTIFY (06) sqid:0 cid:15 nsid:0 cdw10:00000001 cdw11:00000000 nvme0: ABORTED - BY REQUEST (00/07) sqid:0 cid:15 cdw0:0 nvme0: nvme_identify_controller failed! nvme0: waiting Well, neither Windows not Linux have any problems with the device. I understand they may be hiding it or workaround somehow. I'll try setting NVME_2X_RESET in the kernel config and report back in a while. --000000000000ba6db705cdec8812-- From nobody Sat Oct 9 15:35:23 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 2D57717E3860 for ; Sat, 9 Oct 2021 15:35:37 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660070.outbound.protection.outlook.com [40.107.66.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HRTfJ74Wnz3LBY for ; Sat, 9 Oct 2021 15:35:36 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=P3g/i8q8PGZUZ2MW97NvnwZx79e/XyEhPtDo8Wk4ipuHvfl7bG9sPTo9GjDVuF0kN6aMemMCd1C9O7m7KfyvNu/rV81g8Zxcfv0Ood3xpkErc5vUEquayK+z3z0/wnCeg/KXXaN1lKi/3vJ4pl+cVsbTBScJxfb/+E6Pi01bPbjq+x0+HjD2dA4TU07W+aCUzWUnXuoln7dw5n5AjtmjmzCWvuZP/8MU8J+ZiRRrtO4k/FVx4y+zXzkeI7CNh5L1n7GyJVzwd+F6bDj9/ZGjrx+bI3VIZCyPvAMSdqD4E+EMJu+2wyyWpwGvFzurFQtwFmb70GpfplnsXlxYb8i2lA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=rL0rMKXrirhDTXjaKhi3iD9l5vdtRhyTR8zpr/+rv8w=; b=iEc8JuXm4QlcWbDM7VO7KGBOaF6pRHura7CBO+Kk0tiGL3n/IlEmjatlgIR2G5PwqHdXccibstqdXVhajEDb9nwY3DHP+IGKqNkTmgGph99CTjmfwj1rp+FNBhD87nXDrsXQBvcVn/oLTJGmN/IHLXsaXZg0Haovqe+z7Thclf1Gnsh6PubIanxw+cKI3Xvom3nO3tw3/C5I4MGLpXAcg1oAMnlkZIXUtWe735j6a8YVpU3uW4s56+A8fHll5GSQJW8xZiK2c8QDGRMXe4vkMqsK3vf1ykzvRwJ+HwQqswWPDk2Pv70toLMUpy5GirDmtwDFy0LDIpF8cl9KcUmH2g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rL0rMKXrirhDTXjaKhi3iD9l5vdtRhyTR8zpr/+rv8w=; b=YKT7gRfKIUk/8i+VKrfKD9u38dAlDXF/a/94DJfn0f3P9HLePGOpVRtTKJ11gftQFZVkEvIj+Q+kN9MeKP8IIpoRhT6rOO7OklLxapOFrlF/xW7eaTDzex5EfbaUnvwnPW52ujaMH21ecFVU1LXDF9cZ6FKgLDUeCGcPyIKR55VQsu35oYAdWfPba6EDc6XEffn6y05db/OMjirJHtxnDUYK8zFe17BtkklTy0KGmLzqphElc8N2TTyrS0ErORI02TO3abbpo73LGG86QPyATVAgpRtLor5jvkfnSMbOzDOuOi/u6AFi1tbQalmu+snspNWWsWyrCO314uOtPc7bTQ== Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:19::29) by YQXPR01MB4406.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c01:6::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.18; Sat, 9 Oct 2021 15:35:29 +0000 Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::7091:13ac:171f:1c12]) by YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::7091:13ac:171f:1c12%5]) with mapi id 15.20.4587.024; Sat, 9 Oct 2021 15:35:24 +0000 From: Rick Macklem To: Felix Palmen , "freebsd-current@freebsd.org" Subject: Re: Writing large build logs to NFS extremely slow? Thread-Topic: Writing large build logs to NFS extremely slow? Thread-Index: AQHXvRjIhXhFzFqRLESM9Us/FueWtqvKyjub Date: Sat, 9 Oct 2021 15:35:23 +0000 Message-ID: References: <20211007021643.bwglyvrswk2nm3fl@nexus.home.palmen-it.de> <20211009141852.3cmjh7tysnehum7b@nexus.home.palmen-it.de> In-Reply-To: <20211009141852.3cmjh7tysnehum7b@nexus.home.palmen-it.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: fd4650d1-4b20-c4e2-4ddf-13392dd1399e x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 357a0951-e537-4974-833e-08d98b3a6948 x-ms-traffictypediagnostic: YQXPR01MB4406: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: eDYobs5D5k1Q4ogSnBGR2eJziNBCU638XxIZpddtFWZy4+Pcle/SHl8FET5cNsi7u0+bVqNmC6iYsZebZGdD9LbnwbG6CnN+fVWckt5XDvm+n2ZM9QPzru7KnEB6E7b4ox+v+aki3in/BHbowM7S63S24ZB053ukJLl3s2x6xtmVIfcY6/TbD/cq8tFs0xyi9hiJXZJNpZoljgsyt9EC7rZghfoQE5JUtRHEtdeudkGLKqoGxQdx/m2wxuZWexem4ySjKhA0MrsHH7gucrrjawn17GkDWUHDfg6WClZlLVWXkoFAKLWVMYuoEZG0Pwn6wPU/GUxJ6YS5qGh1ENNYdMI2/T7awBcfLRVpvkHvISfoq58Mr/zUdOp/XZbzWSRTD1MnxtIFgmkGzmQOynEg3taQlY92jWccombwW4tePPr00sU3U3S2CTsh4UaFctPotlIMeVm1r/126yFo0XskVILpXgnaquZElFqeW3V40zJdyt7uP0K9H8/q5aXl2Ci4ISbjMSVAaBkLiKBIJC1uFpdy5CQH403KONdQRsPAbPUZu1+NNnTYosiSLjj0PWZmomTJ8iDzW69fi4htz3PLOV+KzaEeu+nMsMjU0rKKsjzow0HdHFoYPhyccBDSsP4IkNd/kAqkQK5q9nTHtvw7KXQBFUi8owR4ALHMTUtn6syTOcco9B8jXXo2olW8d2nOBK84W1cpBggCoP71wZX3c7bAUOqrwZZ0stO4sDs4q/V9I9x8oVFXCpMp9sC1bJyQQeyqDT3UZtrQoY+7MzUVF6QMiCv263GovseD96l2rCo= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(366004)(33656002)(110136005)(8676002)(66476007)(38070700005)(91956017)(66556008)(76116006)(508600001)(66446008)(64756008)(2906002)(316002)(786003)(66946007)(83380400001)(52536014)(86362001)(6506007)(122000001)(38100700002)(7696005)(8936002)(9686003)(55016002)(5660300002)(186003)(71200400001);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?dbZobjl+Hse3iwWDSbEkmKXzWzL/x6haqbzPRaIZKRudy+9lEgdzowtz?= =?Windows-1252?Q?TQflZHTR/+5/La9ZoSMXKAzIN9FNGhASZ4hMPfQIxw2z/JcxSG0+WAuE?= =?Windows-1252?Q?EsBNMCx/HU5PhUVoh2eEQ5IUReh3HUBax9kHoE6mqxpEbj45Ow3VMdea?= =?Windows-1252?Q?G9amWoN/eG2sQiHMs5qZqyFI1MES1M3jebV4YmY5PcIUhObvNRd0RddT?= =?Windows-1252?Q?vuSUvMnuUMGJJEDIvvAcrGIlXqRDLW7Vgkzw1ERkVk2qvz+Edux1/+n7?= =?Windows-1252?Q?f7kxIA7d3zFd+Fkh4NJzjH+WWlBbW7+Ra1sI4c1QQT9LkaE4HjELs63V?= =?Windows-1252?Q?ixe5sGg9F4rjkJSfPkGp2PhoWH6j6zWlhJ7NSWkymo7IufBOlN7PIsL2?= =?Windows-1252?Q?qm/AzBacA1WEJ+aRGB6wtVILi3r0TlUjz7TV5rg4OPxSY/fh53Yse3Dg?= =?Windows-1252?Q?baPAboD/5NSGsXMUC5cOB7y5r7mEFP+/DbaA1NuHeX+/UV6AXmeBQmK9?= =?Windows-1252?Q?oyAqu6VRbzPh1O0Xg6eEeF96i7gFo/Vsb1zE677Ug/Qb9xicLKsTuQBJ?= =?Windows-1252?Q?FawMPiGMnSccdDLiP3LDhN2b9V6Z4FyQfbdlwclfBr5Tir5yiHbl368B?= =?Windows-1252?Q?qR7Xi17N2Cv7w4tbbypo1kSQfzV0yLvTqovoOYZVsdEGmr3/bsM/8D7x?= =?Windows-1252?Q?NCiEfEn/aax3ZGqxvZE4uLg2mDI8n5/QH/0w1U1Rfxc0i7S/zGFSji9R?= =?Windows-1252?Q?KbaF16EYnNTnwQuaoiaV24uP2KUfMMnJKgCO90NNyRfsJ39+Ag1v79gk?= =?Windows-1252?Q?zX0IRdqcgn2e8sutVzRLaYD3mxmz2KRhijJoVpD6OVDuwoAYOs++EmvH?= =?Windows-1252?Q?I+62n4pdgogLavTW8oDr7qn2WeA+tzp/F77tjzs0FVzQZDTMI9LHYpI8?= =?Windows-1252?Q?yhV9Gx7nzje7pnUZCe/IDZ7zmIwJDlujb28h+1vQc2D8T47wq4STq7p0?= =?Windows-1252?Q?603MW05Alcj92cAToPxN8LFkQJk9New7v3OJCRfdQzunMyEadkIlVBwr?= =?Windows-1252?Q?BV4NBEKM/6vTs/6WlscnizkExm/vV2kulQNpQYHexod0Lb4ViEutbsg4?= =?Windows-1252?Q?d1eviKRHCOELWzMQL8GPK0UlLQLwKXXneA09sNwlShPRO4nTQLqg7Mc3?= =?Windows-1252?Q?qGnXtpXP1+Op06y54zwZc9v4gBSOEyX9Z8eLrT9i0yKN6HFXKCJeNoBG?= =?Windows-1252?Q?WZGWfa0kqF5kF3N4TaBXZxtCUAv4HZsodE832bC25HsnZS69b76D9mC6?= =?Windows-1252?Q?C/0RSj7gPtOw8pMqKb4j9g94ebfkMAEY5d9hQ7y5aFYs19izo6uy++Aa?= =?Windows-1252?Q?f3qVKn/cS3RcGmZLOlGl+A1LGepzyewBbQkePyLYEhXqzqi2KDPyBv7H?= =?Windows-1252?Q?RKkB60hYF+J4JN/U3K9MXrqgPGaBNtfEJn6uPM/SEYXpOTE9qU4t5dvS?= =?Windows-1252?Q?9cKhFXQN?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 357a0951-e537-4974-833e-08d98b3a6948 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Oct 2021 15:35:24.0059 (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: UhWYhP+06bxd5OzJzxoHUW0NGpKwYImusrArO9AIfYWkWYKzQw56l/7OHA7l0INVV2315FW9AufG9u6+D6ABUw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQXPR01MB4406 X-Rspamd-Queue-Id: 4HRTfJ74Wnz3LBY X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Felix Palmen wrote:=0A= >I use a -CURRENT bhyve vm for testing port builds with poudriere. As=0A= >this vm is only running when needed, but I want to always have access to= =0A= >the build logs, I use NFS to mount /usr/local/poudriere/data/logs from=0A= >the host.=0A= >=0A= >I noticed some few ports take ridiculously long to build while barely=0A= >using any CPU time at all. On a closer look, that's all ports producing=0A= >a lot of compiler (warning) output, e.g. gcc, gnutls, gtk2, =85=0A= >=0A= >So I assume appending to a large file via NFS gets slower and slower. Is= =0A= >there any mount option I could try to fix this? Right now I only have=0A= >`nolockd`, I also tried `noncontigwr` which didn't change anything.=0A= =0A= Assuming your NFS performance is acceptable for other things and it=0A= is only this log file that is a problem, then I doubt there is much you=0A= can do to improve it.=0A= --> Append (as in O_APPEND opens) are a poor case for NFS, since there=0A= is no append write in NFS. To approximate append write, it must flush= =0A= all dirty data to the server, do a Getattr to find out the file's cur= rent=0A= size and then do the write (over and over and over again).=0A= You can capture packets with tcpdump and then look at them in wireshark,=0A= to see what I mean.=0A= =0A= You could try the "nocto" mount option, which might help, if the log file= =0A= is being re-opened many times, but I doubt it will help.=0A= =0A= rick=0A= =0A= Thinking about alternatives to NFS, are there any news for client-side=0A= 9p virtfs? I found which=0A= still builds with a few minor adaptions, but trying to mount a 9p share=0A= freezes the machine.=0A= From nobody Sat Oct 9 15:50:33 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4FF4817E6120 for ; Sat, 9 Oct 2021 15:50:44 +0000 (UTC) (envelope-from felix@palmen-it.de) Received: from stef.palmen-it.de (stef.palmen-it.de [IPv6:2001:470:1f0b:bbb:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HRTzl46xhz3NfR for ; Sat, 9 Oct 2021 15:50:43 +0000 (UTC) (envelope-from felix@palmen-it.de) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=palmen-it.de; s=20200414; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:To:From:Date:Sender:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=hKw6wNcfZ+HlYHs3tBrNIWVeizJz+3UeBoYBWRaAs5Q=; b=xcW4Is1B1I64eo2PcIogBANQhD MgklaiIOttF/2X2cvqksw3A1insFxrl+04XcqxXVl6sfcfq83peKGiEX7/AZPLTzoTVHPL4ReuryM 35OrRGrm8g8aPOxSsZKSlGM406zLNNLgWdC8dA+deYf/IUUuk+c2y7T7CPtSDMQvqyy8lmd5VVRtp 1BnuMwwkUkiTYBHAa4jf7uvLff/Wl/044A+al7JwlEda1zwJlc+8KwvPh2XG9wVbZ6Xmlh1ud0x+Z F/xT5GwGCUDLOaV50gCGr5MNZqzPzVphIB6V6RenYFURM8UlN4bbZTr0BlzpufJiDUNSuPkyps7XD YRF4/FnQ==; Received: from [192.168.71.101] (helo=mail.home.palmen-it.de) by stef.palmen-it.de with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1mZEcU-002ndk-6M for freebsd-current@freebsd.org; Sat, 09 Oct 2021 17:50:42 +0200 Received: from nexus.home.palmen-it.de ([192.168.99.2]) by mail.home.palmen-it.de with esmtpsa (TLS1.3) tls TLS_CHACHA20_POLY1305_SHA256 (Exim 4.94.2 (FreeBSD)) (envelope-from ) id 1mZEcR-000NXD-Bj for freebsd-current@freebsd.org; Sat, 09 Oct 2021 15:50:39 +0000 Date: Sat, 9 Oct 2021 17:50:33 +0200 From: Felix Palmen To: freebsd-current@freebsd.org Subject: Re: Writing large build logs to NFS extremely slow? Message-ID: <20211009155033.fckg4i7zqo4yt2te@nexus.home.palmen-it.de> Mail-Followup-To: freebsd-current@freebsd.org X-Face: /1K@t"h.}e~pR@]c7HorQ!T`F^RJCa'BCr#e>IKA{>C/9OTGB4|xh"y2{?1Z5M i2w"AH^pN_LlHR^{+f',_Np~;.B;!M/bL}*qk]p5*r7F5vW};{:@4u5S?T&f0$7BJ-71Q5SV]:v$`5 A0[DZ:=?S52x8HJ~5@^P_\T@MsjG{R( Organization: palmen-it.de References: <20211007021643.bwglyvrswk2nm3fl@nexus.home.palmen-it.de> <20211009141852.3cmjh7tysnehum7b@nexus.home.palmen-it.de> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="khodntlu4fcbzk3t" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20210205 X-Rspamd-Queue-Id: 4HRTzl46xhz3NfR X-Spamd-Bar: ------- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=palmen-it.de header.s=20200414 header.b=xcW4Is1B; dmarc=pass (policy=none) header.from=palmen-it.de; spf=pass (mx1.freebsd.org: domain of felix@palmen-it.de designates 2001:470:1f0b:bbb:1::1 as permitted sender) smtp.mailfrom=felix@palmen-it.de X-Spamd-Result: default: False [-7.80 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2001:470:1f0b:bbb:1::1:c]; TO_DN_NONE(0.00)[]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROMTLD(0.00)[]; DKIM_TRACE(0.00)[palmen-it.de:+]; DMARC_POLICY_ALLOW(-0.50)[palmen-it.de,none]; RCVD_IN_DNSWL_MED(-0.20)[2001:470:1f0b:bbb:1::1:from]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[palmen-it.de:s=20200414]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_MED(-2.00)[palmen-it.de:dkim]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; RCPT_COUNT_ONE(0.00)[1]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --khodntlu4fcbzk3t Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Rick Macklem [20211009 15:35]: > Felix Palmen wrote: > Assuming your NFS performance is acceptable for other things and it > is only this log file that is a problem, then I doubt there is much you > can do to improve it. Yes, that's the only problem I found so far=E2=80=A6 > --> Append (as in O_APPEND opens) are a poor case for NFS, since there > is no append write in NFS. To approximate append write, it must flu= sh > all dirty data to the server, do a Getattr to find out the file's c= urrent > size and then do the write (over and over and over again). Ok, thanks for the insight here! So maybe, I could have a look at poudriere's code? If I understand you correctly, keeping the file open and just issuing more write() calls wouldn't trigger that problem? > You could try the "nocto" mount option, which might help, if the log file > is being re-opened many times, but I doubt it will help. Well, I take any suggestion, so will try that as well and report back, thanks again! Side note, please don't CC/To me, I'm subscribed the list ;) --=20 Dipl.-Inform. Felix Palmen ,.//.......... {web} http://palmen-it.de {jabber} [see email] ,//palmen-it.de {pgp public key} http://palmen-it.de/pub.txt // """"""""""" {pgp fingerprint} A891 3D55 5F2E 3A74 3965 B997 3EF2 8B0A BC02 DA2A --khodntlu4fcbzk3t Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEqJE9VV8uOnQ5ZbmXPvKLCrwC2ioFAmFhukkACgkQPvKLCrwC 2irRMQf/cHZ+l+ta4CW6lojzmkYsb2I+p3WnRKXJM++5XF6SHcq36W2V8+EBfXcN c9PYCbtdvPE/1+X9HG6RPAOqC1uaiRONh7qmCBtYlPCjEjOOHAugXXpodzIRG3LW EL1vKKW2OlqgxVVxVHXFaKCjqeqewkfZzONGMJ4yQTfPmllaAuLkJgb8CVmC1A0D 1xPWf3Uk/GSApSLlmyTFT064MDIK6hg3vkBNVLicZuaFn8hv84n8O8jQrS8R0HAi u0dvLbXgJM7eztYbev+39Jh5IeOr9A5ZI7/ZniCXm0Z4iOWwLDuOr/iEAM9JspFQ BfO5Ec/H99qzEnDUFq36DEox4TWLpg== =U4rE -----END PGP SIGNATURE----- --khodntlu4fcbzk3t-- From nobody Sat Oct 9 16:09:52 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id F215A17E92B3 for ; Sat, 9 Oct 2021 16:09:59 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660059.outbound.protection.outlook.com [40.107.66.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HRVPz5Bjwz3QX8 for ; Sat, 9 Oct 2021 16:09:59 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TU91XMtZqbGdeEX8E773+wJEP3geB9qjzYxITzyRJpUkBkPRy7T0dIOogJsvK72yU8ZrB82IsGf/tkfkoiVLZBL4WFHicPcEQ8heb96ka9DMOJKfmO9laLxQBlF/8PqswvvyHH+eKyyc2gobGd78D1wb7Eq76EQ6+jwP9nsie1NBktl30pvRnSQUgmQb1JOZ66ktaOkb9n0HHr2071iyAZgfHFrUqzoaZsh1lvYvG26Jm2qvav7z+FWC7x77TPmZUUxwAPQFl7qEfzK7bLRfF+dHosbG1ymJo2Vu09Qpa1DzJAwXq53g4ndM9tY9jCOp42fBvNH9wTzOhW4yIPhD6Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=s8jLoPe0HQuQj/i519e0Dx8diGPbCJg6++a1Ep4Y4gc=; b=MWqYe+EHu+6He+CUCrWvuEhfjKFFLb5W4Q5n+Dlg7kzW2ESkJcv5vsRjhdsDz31qkLMz9BPh1TlzNhA6lPauU2u+CcSAchdS3UpsF5AmR0aC33ctOKo5y5ulphlJaLIhB94MylbSM1ggofoTegtYPAxhZeFqQfw+LU8mdjLbhBJ2MoBNCm2BhTMDxa7rCrhPKn5PQLvvJcEpZwefIIZzThG7qQhBWj00S/woNifXljiMNEpBGNMNNL4i5BVGroNpN9sOC/2MErVOQ/825w7/H+IoHqOQ2gpbWiGR6JGRcuuW84MiMWSu2OUtx/wBWRnPkoo+2v2YuP0coSMsuWEfMA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=s8jLoPe0HQuQj/i519e0Dx8diGPbCJg6++a1Ep4Y4gc=; b=AElXxkh2hVVeZigzHlyufyUk2c761xNCpF8bWBxHLTVHWs4ilYadtwJT0T4TIDbTYR/xDcyUdHQS0NQ+sFy3WoOqc3Mf4xnUxyQO5EHJffSRCDBWPcccTv4r6xnZx7ehJAh06SacGUmwWCeOdfMKHqKuRPoO8UVVo8X38mZa5XR4lh/JR0stmgXN3CDSj46mH6O1ykqXcjJWBZhYcdqhVnQzXeajEd1vyzuhCeaNF901qCn2hc5q1rkqwoCE7CEghAaRhzsB2xbRfJYaiaP/JU1+NNiCjxqF62eEoirH3il9eX4rJL66kX0A4TGVW/zPMWmqRDjzlVECA8fAEWqEhg== Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:19::29) by YQXPR01MB2711.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:45::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.22; Sat, 9 Oct 2021 16:09:52 +0000 Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::7091:13ac:171f:1c12]) by YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::7091:13ac:171f:1c12%5]) with mapi id 15.20.4587.024; Sat, 9 Oct 2021 16:09:52 +0000 From: Rick Macklem To: Felix Palmen , "freebsd-current@freebsd.org" Subject: Re: Writing large build logs to NFS extremely slow? Thread-Topic: Writing large build logs to NFS extremely slow? Thread-Index: AQHXvRjIhXhFzFqRLESM9Us/FueWtqvKyjubgAAGXICAAAQr+Q== Date: Sat, 9 Oct 2021 16:09:52 +0000 Message-ID: References: <20211007021643.bwglyvrswk2nm3fl@nexus.home.palmen-it.de> <20211009141852.3cmjh7tysnehum7b@nexus.home.palmen-it.de> <20211009155033.fckg4i7zqo4yt2te@nexus.home.palmen-it.de> In-Reply-To: <20211009155033.fckg4i7zqo4yt2te@nexus.home.palmen-it.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: 7cf544d2-f350-9973-95e2-db64a6ab6136 x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: eecd1837-7cd5-474d-5654-08d98b3f3a45 x-ms-traffictypediagnostic: YQXPR01MB2711: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: PPK9uIaj1W6tfV+Eacie+rM1WSOOqsibxyeTuhwaNwG55XQklH48JptdVkvcqn6HiP9je1Vq4vLx4NvKY6pMbEZhEnP/B4UKY9KCwEG9fRkVDZ+9PGpXEl1XpediS8la0QTnf9LWl6lKSxCPXyD5ArLf5fac52afI+OZUgQTdEdHGEuMUWQBxnihg0N7Qe0iCLRcDTCCohiQiPuqDRflnpan/59B/kdFgGLfwuGTWpn7vSZ7wRlxLS5pg+jCY72Nw+J40ijPPC34zjmLs94M53zAsSrBvfEPGjeNovy3lxLmYeHpwjjOUcO1wTsw8fObunWc3dIvnouYfdhATEwVj99hTINy0E69jCndKbLqvXKr1bjOmTFWIby2R7rcCi6lGmJ6SRhh5mPteoOEaUcN9dX8vUubG4l9JrsokbcBJVWDIDzyicX3ZOwYMyrB/AXQPXUTOck2ClIj6faPGNZU41ijUzatSEgcw/bOjTK/oTcVyHacYvERagbSMWaxfgGYuBDQKUhZQ5EMAEYt3hfr5Kjdm5o8nTIsVAHucERAV5ZFg+nMEBnhpSvcHTZPBh+3JyQm4oIRLQpSbti0JIbO+HXx9GstaRQHWjmHlR1B4C+W9R49wbr9/MEchiQL1pSLzTT7+u8EYTfb4Quh0NGxlrJawGK5LJnTNVCWBCF4BVA+blKX0pPaV0uekYdOiWkhRtiUcSp2lDd87DHMRss+uyDJgN8ZLVp2DJD1+UcwzseOyc31TVJsN73GO+ZObFAQ5QESWeHGlBNHgmCBw++kLSpTHD3ec4Ra/mM0QPyXBGg= 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)(7696005)(38100700002)(6506007)(5660300002)(83380400001)(8676002)(110136005)(8936002)(508600001)(316002)(786003)(9686003)(33656002)(2906002)(122000001)(966005)(71200400001)(55016002)(186003)(66556008)(66476007)(64756008)(66446008)(52536014)(86362001)(38070700005)(76116006)(66946007)(91956017);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?Windows-1252?Q?p7bbIJN5FRI608VZoUzn7rsLIEz+ZTapRSelviEVH9QGINpawOhv1FaM?= =?Windows-1252?Q?YhWOeHv7thaHznmS4ZBS9tJGrj3Tq3EUDj5ArB4kFXdNUhR55n+HFFCz?= =?Windows-1252?Q?2xkpXUNK8usHJ+0LewzBMY6hTHeqgDM0Ik+rXtLWOvL0DqnbGZr3pPVO?= =?Windows-1252?Q?ZLMedlqG++Mj/9a4MJNy7StyzCAwRhuXRAQxGfUr8h0hd15RKScIqHYF?= =?Windows-1252?Q?ezrQeuVEr8qxYESR2Jg8WxNe9X6IHjD4oCNA9o9VnUThC9gfmNrLZfHn?= =?Windows-1252?Q?kRYaWHsOXbM+9pdQRaWrSt8ebxyEE2E87ngLNIuSVkepdzUkzH1dR0CE?= =?Windows-1252?Q?wsH88XMx5SHaEPlYdY+ER74twrcjcRqhVoBMmfi22a/RAd444glrfaw3?= =?Windows-1252?Q?WcUafGZhdnyw3g0JuMboeHCBtnLriZKjPzK7n7v8OlLNqOF8H2KhZ1hS?= =?Windows-1252?Q?d3LtNBJpPd6KezDah6bLOZpLQSgCXkT85ePpGha9wijbkifX+jlohDYH?= =?Windows-1252?Q?d8O6U1eRGcMxuLGyKTQcpxsbhOdUFht0ZwjicqEpl+sTz1kyT4BhtPGj?= =?Windows-1252?Q?dEef4wLOCOa2vyGUJKH0oRZnOuBt0remxF0BOp2nA3kztlwd5vjoY1qP?= =?Windows-1252?Q?BUEUGXyGrE4LftqtBOUb2WUmG/YH6zARTeZ1MJU0INd6GhH4psKr1Rnx?= =?Windows-1252?Q?rE+fF/LSg0fH+qPYvl+laG200bsMjC5yOR3Wsi7mkaCzSqlrXhs5pZ+y?= =?Windows-1252?Q?6GHEExoedo2+D2Mj6Dh12w009rFp1JU+A566M1iiO/VdImNUmIAfzjK6?= =?Windows-1252?Q?xlSu5TPaYUcNzfMbO6Squayu6GEPE1fWoS2IY9lFOHoP6oyDgm/u/BwD?= =?Windows-1252?Q?TWE0ZachryHV7IN+P9CF2n0Zp9UI65vpeJ+e09olOQZOYkIfTW9qqxSg?= =?Windows-1252?Q?YbP5k2KAZwEbLRit+8rHeFUw1pfiWq4dWRnpczy9lEzIV735d+I6G5Li?= =?Windows-1252?Q?j7kRmnTjAigvm2edKm4FmDcAYz3HN51RxU5DFjbQynqRJWNYSjg3jrHw?= =?Windows-1252?Q?DMCnoHHdpB1mp+OEFSljKL96XdLXIaOChzGlPJx0G4Hkws6HZZ4Y1iw7?= =?Windows-1252?Q?2INXFxoQvOqER6wzX6s+8WFndAqemOo6eqrwdZFrZVFf9Ri9UeHNgjAY?= =?Windows-1252?Q?o4hMdIdRHbsLWC38OGzRx2ZVHXZJd5OOdEFsZEDF/yVzW8F/3G70xFLC?= =?Windows-1252?Q?wLPbVgs9Ec1YLY3cA1ounHjnofV4ilJyY6STs8rGFOVNMf2JKkpOAunF?= =?Windows-1252?Q?51lCraG6CSQn2kSl+WscHEawsv3I+SSRmj6N0fO6TKwGNu5O/vYHmBsR?= =?Windows-1252?Q?De+M0otXz6sDg7ZQRW8Eu5i0ax1AxS62nEUspUl9j3s1SUgZuj1hj+ha?= =?Windows-1252?Q?3fCMOdeIZ9ggrq9HWR5+dxFwb5eMoV/EGxEFjnTPIJcls5zQy1sqtuOE?= =?Windows-1252?Q?FnGxkt5m?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: eecd1837-7cd5-474d-5654-08d98b3f3a45 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Oct 2021 16:09:52.4709 (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: 3eT+T2c27KhXMWdGTzhjhe4WBKjP3xDHBRc3mHk057MyLFEcIuNevBxzN0hlA+P/x7Pxi9UioodEgT/cv6a79g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQXPR01MB2711 X-Rspamd-Queue-Id: 4HRVPz5Bjwz3QX8 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Felix Palmen wrote:=0A= >* Rick Macklem [20211009 15:35]:=0A= >> Felix Palmen wrote:=0A= >> Assuming your NFS performance is acceptable for other things and it=0A= >> is only this log file that is a problem, then I doubt there is much you= =0A= >> can do to improve it.=0A= >=0A= >Yes, that's the only problem I found so far=85=0A= Another thing you could try is turning off synchronous writing at the NFS s= erver.=0A= # sysctl vfs.nfsd.async=3D1=0A= and "sync=3Ddisabled" for ZFS if it is a ZFS file system that is exported.= =0A= =0A= However, BE FORWARNED:=0A= Doing so violates the NFS RFCs because it can result is data loss/corrupted= files=0A= that are being written when the NFS server crashes/reboots.=0A= Only do it if the data being written to the NFS server is not particularly = important stuff.=0A= =0A= rick=0A= =0A= > --> Append (as in O_APPEND opens) are a poor case for NFS, since there=0A= > is no append write in NFS. To approximate append write, it must flu= sh=0A= > all dirty data to the server, do a Getattr to find out the file's c= urrent=0A= > size and then do the write (over and over and over again).=0A= =0A= Ok, thanks for the insight here! So maybe, I could have a look at=0A= poudriere's code? If I understand you correctly, keeping the file open=0A= and just issuing more write() calls wouldn't trigger that problem?=0A= =0A= > You could try the "nocto" mount option, which might help, if the log file= =0A= > is being re-opened many times, but I doubt it will help.=0A= =0A= Well, I take any suggestion, so will try that as well and report back,=0A= thanks again!=0A= =0A= Side note, please don't CC/To me, I'm subscribed the list ;)=0A= =0A= --=0A= Dipl.-Inform. Felix Palmen ,.//..........=0A= {web} http://palmen-it.de {jabber} [see email] ,//palmen-it.de=0A= {pgp public key} http://palmen-it.de/pub.txt // """""""""""=0A= {pgp fingerprint} A891 3D55 5F2E 3A74 3965 B997 3EF2 8B0A BC02 DA2A=0A= From nobody Sat Oct 9 16:21:35 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E3BCA17EB28E for ; Sat, 9 Oct 2021 16:21:43 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660072.outbound.protection.outlook.com [40.107.66.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HRVgV6BlBz3hn5 for ; Sat, 9 Oct 2021 16:21:42 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BnHSKvLNkPBwuBLsdBIpYRjB0687WPyIW04U9Iph5W+D5IhA+1+vgTExFVuhG9ThQ6swGgvwE4aqEEKw4eGwBZSH52sic/A+yv5riQPpuf2vgxuMg+uPdViQR5d/+hPeu7EitUCBa7VtmLKOdJSOzb33LvvwCrgtCmCLSfDh5yehCLv31xSbV1kDrQ3Pwz0DQID5XUvgRQILQi4T7127xWcty6B2kCE3nYsM4QK5jkATgveGxHrUnHWLtcysB33QT4dRUNuTpAL7oMEAvnFfKYbad6lFzwzsqC20AtnQN+yO126zMt2VikBqsfMh33AVcmkwQxVNVGoYySvnLJdKZg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=CTbBPegpMJDAsvIfE3RTjzKGgcrM3mMPintCHQoL2JA=; b=HTPkiosuN61CCqLVKnJ88kPs5gIdDWX19ESQKnVobZNOas2AFesUMZQVnpHHyvw9zrB8bj80JyCp09a17JJjpEkC9ge8kTW4aiZcHAbvZH40bv5lXYU6mQ7bGquiCwLtW/aHdQ+GaN4tmpOeslfppJ195WhbA4K4R+sPkCBIqf+tsAimfgIw7YHn9Ztiwjas530DZjnV+mz17QQZbq8ZUX0hbzsuzDjZPJRyF+dDHGBRZpwt6X50rumIfzFOx4JRnoUKwq75VIIjhl+poW65DFp7EZdF8VqbJ/KUGCkspm3GfjYHBTdlqJuKfusch9jFsP7ZN4XDCs03rWCauGMfgw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=CTbBPegpMJDAsvIfE3RTjzKGgcrM3mMPintCHQoL2JA=; b=c0xls1684k5gznIAyR6jPrzQ/8w8aW5nWNqHOp4FMWtWFMApNBoR63532HSXXOjZa9q8dl8XoBxFrljWlabBj9ZB6piS+bF59dX7myBKbGrAOcMYXEPk+bIKnskrqfvEg3QhmFxLqyp8825zjl6MkZ0+z1kODIZ3EAx8W9UMtIJfI+5h2TBuNYCI8TwSNS1WQEREeAHwjpxlT1KG/KykI4GI4LTSWrilse/2Ifae3yQAL3JAWza+R1f3E1U3ZYR7ZlQQZlJ3ECu9rOJtAW7bZDCcCUgDsIHSnwAT2GPYmdLMzAEoXhmgAuyTjZUuhVTdY9NARe8NDo9m4s/iiaeL0g== Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:19::29) by YQBPR0101MB4888.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c01:23::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.19; Sat, 9 Oct 2021 16:21:35 +0000 Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::7091:13ac:171f:1c12]) by YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::7091:13ac:171f:1c12%5]) with mapi id 15.20.4587.024; Sat, 9 Oct 2021 16:21:35 +0000 From: Rick Macklem To: Felix Palmen , "freebsd-current@freebsd.org" Subject: Re: Writing large build logs to NFS extremely slow? Thread-Topic: Writing large build logs to NFS extremely slow? Thread-Index: AQHXvRjIhXhFzFqRLESM9Us/FueWtqvKyjubgAAGXICAAAQr+YAAA4Kv Date: Sat, 9 Oct 2021 16:21:35 +0000 Message-ID: References: <20211007021643.bwglyvrswk2nm3fl@nexus.home.palmen-it.de> <20211009141852.3cmjh7tysnehum7b@nexus.home.palmen-it.de> <20211009155033.fckg4i7zqo4yt2te@nexus.home.palmen-it.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: 1e332fc8-1705-dca3-5459-10f6e715a7cb x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7a2116bf-a9a6-4cc3-fbe9-08d98b40dd06 x-ms-traffictypediagnostic: YQBPR0101MB4888: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: WsW6qpGQ8WUn/A+Cd0nYjKBPDkhkZtrIoNo6dFz4wXlLXb667vs+CcRnZa+xkikGPVwy6rnEn4ezYdidlmISnBrqlEQpxMT9qTuBq66k2Yo8IgJKgMFziYbylvIhpiv2ToMbJUGwRqVBUjL2pKYfDY6J3e1aiDam5/dX80zIs6ErPxRWD2SqsCfNhO4e41DUbCM7ivU1pspVJy3HOfe5ITJsdHS9yPbz8HzP9Hn7HoVYWe2/pkbteb2Du/SnM+vgHFeRz0QiLR5GRbpYk6A7GO+7Kv8ewAg4M9u55271q+LR1VNwB/31Z6r9umuyZAest5K5WVhytaQqjOP9LkoX2aLTmefq/yciDe1gQEcdAzPi2wZMKRQL13fIsVEJ2xX8Jpmetyvu6Mnvs73HgxbryClzmILgmu4KJGligW1vokINxC9C5FdKZSPVpPVB2zeoA7Jgtd+vKOajJYv/T2uw3ZoTbWJ5rG0FduNxPR2A2UFNqTfPMW2H0BBDIi2/w3lB2LuRMRKttQXDKtdAoUSHGFoR37AV0sW+G9gUdqM/v9TU/SFTaszJtCY4ajnkuY23j7R85BN5mF8C9XSEDekpOurXo03VM4phCgpG9Z67QmV5tCGlCsLRS4lpaszYRff8OdRyizlUYjsis5D4D89DFktFP3pMp9wyX2a1bDTbP9AU67Au0FaiHyyg+I9RX42ASgsmlrgboltBCUkkIkdKr8jPHs72tVEgwTL7V2RMxK9J1OLLps3wOJlub9ld0yvsdB65KnbYRtgDqvgF4d9tyA== x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(366004)(2906002)(38100700002)(7696005)(2940100002)(55016002)(5660300002)(186003)(66556008)(8936002)(64756008)(66446008)(71200400001)(4744005)(66476007)(66946007)(91956017)(76116006)(9686003)(6506007)(52536014)(38070700005)(316002)(786003)(8676002)(86362001)(966005)(122000001)(508600001)(33656002)(110136005);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?NHY7IBvEH5vRuXLPjMLNtI6NYAaGQg+q6+XM+KPFx9RL5SUODg0f69loF9?= =?iso-8859-1?Q?6HEY8rwJfTCW+YcQJ/ILQvzB163dNlGopUoCWk/uUpurgKMQKu4Ls0mpJ6?= =?iso-8859-1?Q?5rGZCyrvaMLeLq8wPYICOeNRrngwylUFjcKm2CvF6rTGDVAlOyiMKq8H/K?= =?iso-8859-1?Q?11DCm0n5uhVn19Ch0QvgHA1gkDPB8OxaatrFc68sJfXzmfW+c8fjs+td/d?= =?iso-8859-1?Q?+6gJVIwHxWG1av2y2mqSSJkoNSIYBMXQ/LgT1WcV3cd6/UzNV2P9xODbi2?= =?iso-8859-1?Q?4ohGR3Lzc725GBhZYRaOGFxrsdlti4HEBwar6nsHtaULPi5qwySiJDNCR/?= =?iso-8859-1?Q?82jLMzhObI7phPuF80I6b2XFHz1+QJgEHn6Lp6JV1S3hNSvNPOaBHpGn6N?= =?iso-8859-1?Q?ZVq0Ytgeq+T0Ox6s1wBmlm3WfBA49jymyOUf4PejjDA8Rv1AMgJGBV2eSf?= =?iso-8859-1?Q?62UmcLKQI4U4Ux51sfI/DYmuDukqFnD01dKQgyxkYCl1QOY/qeBM9Ny3VB?= =?iso-8859-1?Q?hgz8yX44DQ6FflF2Mw3CmUvKVDmq+Cb0SguXxKuHP1DaelasVXmgtr1y2j?= =?iso-8859-1?Q?Bj2zGjp5qgbi6kU45Hslq1TBaMtkG++FwewCD8SY21Bv1/W0fWEqB7E0Ej?= =?iso-8859-1?Q?3hJmbKhigclt+RsjsBx44hNTo+4xyKmejsstyGyGv2/iuOcqlNG+FjoGWJ?= =?iso-8859-1?Q?M/QPBWrhgdCfKYbqC4Z6g87TzmmkaFPs+QByzBznlKWdBcchqVMCBjmqUy?= =?iso-8859-1?Q?Z+BGwpPs4vIN0sgpKst6+8ufRG62E+Dxe/RBhxAfzAnkppiQrce5M0D+ZG?= =?iso-8859-1?Q?1SoeGJ6xDOO8ZMFKJ0laY6pefauRIgzH27UJC+8QAN51bNcpJBcyn4qqZk?= =?iso-8859-1?Q?UeaaDvBX0WEkvAb9BUKNbZRZpxV9U7zWudXLhU40BWUWMPQYf1qZzNTfBr?= =?iso-8859-1?Q?UnUK0HVMSxJyxuc1l0qgKHSw2zug0WdvYnkquaDu4Ddx+JM+BHQAdj0d5x?= =?iso-8859-1?Q?e5N0DnqhJ9a3rOuFjVHkTQ4ilbv1MseqyWK52D2qlhhDAaFbFHtMmPcKI5?= =?iso-8859-1?Q?HHP6P8SlT2h9ka77+ziku22QE1NOIqVOwKWX1UCjvuX8M8ApIqcekoG7S5?= =?iso-8859-1?Q?5glUIB7hRR9UoZWDzs/ke8eyKxjx3PN7HmClm9U4rvvsmaiqOrcKqJFKFO?= =?iso-8859-1?Q?nyvEOt3vCsVlE/g8PHSs41gJbon/o72xDyvuvf1tU9xnkvn95yM4xdiCJw?= =?iso-8859-1?Q?q+6CYO1CXQyITQmdYMriiTzRUcYsdaATEgx9noWDRUB5VjHHySvt9Y1ESo?= =?iso-8859-1?Q?0YQcgSOuK4RWE0AWxtLN4TZS+1Ne3v40p6FE6uQcZOdkcmyPdK0K6EfFS4?= =?iso-8859-1?Q?gbaWuzqARnJfF7aPtj7lqXFK+Adw8/pBkKwqIcf7RW3TEbzLG357PGj6NJ?= =?iso-8859-1?Q?DWzXjdyDSzpiRlUm?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 7a2116bf-a9a6-4cc3-fbe9-08d98b40dd06 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Oct 2021 16:21:35.1006 (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: WS37SNi6DuYANyolq0xEy/5it4gsTpHobv5kVD0Je9eqGWxBQ5CmGX5iDuHnck/aoSho1kc8RAqx6lxqbVR0qg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQBPR0101MB4888 X-Rspamd-Queue-Id: 4HRVgV6BlBz3hn5 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=uoguelph.ca header.s=selector2 header.b=c0xls168; arc=pass ("microsoft.com:s=arcselector9901:i=1"); dmarc=pass (policy=none) header.from=uoguelph.ca; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.66.72 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-4.99 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector2]; FREEFALL_USER(0.00)[rmacklem]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[text/plain]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[uoguelph.ca:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[40.107.66.72:from]; NEURAL_HAM_SHORT(-0.99)[-0.995]; DMARC_POLICY_ALLOW(-0.50)[uoguelph.ca,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US]; RCVD_TLS_LAST(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.66.72:from] X-ThisMailContainsUnwantedMimeParts: N =0A= Felix Palmen wrote:=0A= [stuff snipped]=0A= >Ok, thanks for the insight here! So maybe, I could have a look at=0A= >poudriere's code? If I understand you correctly, keeping the file open=0A= >and just issuing more write() calls wouldn't trigger that problem?=0A= Nope, I don't think keeping the file open would help much.=0A= However, if the file is opened with O_DIRECT, you could try setting=0A= # sysctl vfs.nfs.nfs_directio_enable=3D1=0A= in the NFS client machine.=0A= =0A= rick=0A= =0A= > You could try the "nocto" mount option, which might help, if the log file= =0A= > is being re-opened many times, but I doubt it will help.=0A= =0A= Well, I take any suggestion, so will try that as well and report back,=0A= thanks again!=0A= =0A= Side note, please don't CC/To me, I'm subscribed the list ;)=0A= =0A= --=0A= Dipl.-Inform. Felix Palmen ,.//..........=0A= {web} http://palmen-it.de {jabber} [see email] ,//palmen-it.de=0A= {pgp public key} http://palmen-it.de/pub.txt // """""""""""=0A= {pgp fingerprint} A891 3D55 5F2E 3A74 3965 B997 3EF2 8B0A BC02 DA2A=0A= =0A= From nobody Sat Oct 9 17:09:13 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 8503B12D087B for ; Sat, 9 Oct 2021 17:09:21 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HRWkT3693z3nfh; Sat, 9 Oct 2021 17:09:21 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (tensor.andric.com [IPv6:2001:470:7a58:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "R3" (verified OK)) (Authenticated sender: dim) by smtp.freebsd.org (Postfix) with ESMTPSA id 879B821644; Sat, 9 Oct 2021 17:09:20 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtpclient.apple (unknown [IPv6:2001:470:7a58:0:e42e:3b09:eca2:fb60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id BCDCF4FFDD; Sat, 9 Oct 2021 19:09:18 +0200 (CEST) From: Dimitry Andric Message-Id: <94E84785-8F8C-4E90-A437-929565F5C968@FreeBSD.org> Content-Type: multipart/signed; boundary="Apple-Mail=_3B2C8B46-4219-4A27-B4C7-E8B990BF4F49"; protocol="application/pgp-signature"; micalg=pgp-sha1 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: clang/llvm-tblgen --- ld: error: undefined symbol: setupterm Date: Sat, 9 Oct 2021 19:09:13 +0200 In-Reply-To: Cc: FreeBSD User , FreeBSD CURRENT , Baptiste Daroussin To: Warner Losh References: <20211009094624.3f3cacc8@jelly.fritz.box> <2FCA108B-29E1-48EA-A8C7-BC621CC6F963@FreeBSD.org> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_3B2C8B46-4219-4A27-B4C7-E8B990BF4F49 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 9 Oct 2021, at 15:40, Warner Losh wrote: >=20 > On Sat, Oct 9, 2021, 5:59 AM Dimitry Andric wrote: > On 9 Oct 2021, at 13:37, Dimitry Andric wrote: > > > > On 9 Oct 2021, at 09:46, FreeBSD User = wrote: > >> > >> On recent CURRENT (FreeBSD 14.0-CURRENT #2 = main-n249971-0525ece3554e: > >> Fri Oct 8 15:17:34 CEST 2021 amd64) building of an 13-STABLE based > >> appliance failed very early in the build process of the 13-STABLE > >> sources as shown below. 13-STABLE is most recent, since the sources = are > >> fetched every time the build process is triggered. > > ... > >> = /pool/home/ohartmann/Projects/router/router/apu2c4/src/tools/install.sh > >> -s -o root -g wheel -m 555 compile_et > >> /pool/home/ohartmann/Projects/router/router/apu2 > >> = c4/world/amd64/ALERICH_13-STABLE_amd64/pool/home/ohartmann/Projects/router= /router/apu2c4/src/amd64.amd64/tmp/legacy/usr/bin/compile_et > >> --- _bootstrap-tools-usr.bin/clang/llvm-tblgen --- ld: error: = undefined > >> symbol: setupterm > >>>>> referenced by Process.cpp > >>>>> = Process.o:(llvm::sys::Process::FileDescriptorHasColors(int)) > > > > It is complaining about ncurses functions; it seems that even though = the link step gets -lncursesw added, it still is not able to find the = symbol: >=20 > Okay, this is because recently on -CURRENT, libtinfow got split off = from > libncursesw: https://cgit.freebsd.org/src/commit/?id=3D396851c20aebd >=20 > This affects such cross-builds obviously, and manually adding -ltinfow > to the link command line makes it link correctly. >=20 > However, the 396851c20aebd commit is probably not suitable for MFC'ing > to stable/13. Maybe we need to put some kind of kludge in > share/mk/src.libnames.mk for this, or in the top-level Makefile.inc1? >=20 > Baptiste, any ideas? :) >=20 > Add setupterm() to libegacy as a nop. That's not enough I think, it requires more ncurses functions than just setupterm. And it actually calls them and checks the return values too, IIRC. :) -Dimitry --Apple-Mail=_3B2C8B46-4219-4A27-B4C7-E8B990BF4F49 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCYWHMuQAKCRCwXqMKLiCW o4loAKD1KObbUMYTf6WSCVX+8jJsYg/ccQCfUoTYpmf662SXWrfQXmSSqZaejrA= =gTUS -----END PGP SIGNATURE----- --Apple-Mail=_3B2C8B46-4219-4A27-B4C7-E8B990BF4F49-- From nobody Sat Oct 9 18:51:12 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id A5B8212D9FCC for ; Sat, 9 Oct 2021 18:51:21 +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 4HRZ092n95z3vQw; Sat, 9 Oct 2021 18:51:21 +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 199IpDal096010 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sat, 9 Oct 2021 21:51:16 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 199IpDal096010 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 199IpCKS096009; Sat, 9 Oct 2021 21:51:12 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 9 Oct 2021 21:51:12 +0300 From: Konstantin Belousov To: Michael Butler Cc: Mark Johnston , freebsd-current Subject: Re: intermittent bsdtar/jemalloc failures Message-ID: References: <2908d747-8606-84d6-60b5-249c0d396b6b@protected-networks.net> <31be6e3a-f303-ce78-4dab-5dcc77ed0464@protected-networks.net> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on tom.home X-Rspamd-Queue-Id: 4HRZ092n95z3vQw X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Fri, Oct 08, 2021 at 03:36:18PM -0400, Michael Butler wrote: > On 10/7/21 20:19, Konstantin Belousov wrote: > > On Thu, Oct 07, 2021 at 05:43:14PM -0400, Michael Butler wrote: > > > On 10/7/21 16:52, Mark Johnston wrote: > > > > On Thu, Oct 07, 2021 at 04:18:28PM -0400, Michael Butler via freebsd-current wrote: > > > > > On 10/7/21 15:39, Konstantin Belousov wrote: > > > > > > On Thu, Oct 07, 2021 at 03:28:44PM -0400, Michael Butler via freebsd-current wrote: > > > > > > > While building a local release bundle, I sometimes get bsdtar failing (and > > > > > > > dumping core) as follows below. Worse, as can be seen below, it doesn't stop > > > > > > > the build unless I happen to notice and it yields an incomplete package. > > > > > > > > > > > > > > a usr/src/sys/netgraph/ng_checksum.h > > > > > > > a usr/src/sys/netgraph/ng_message.h > > > > > > > a usr/src/sys/netgraph/ng_echo.c > > > > > > > a usr/src/sys/netgraph/ng_gif.h > > > > > > > : jemalloc_arena.c:747: Failed assertion: > > > > > > > "nstime_compare(&decay->epoch, &time) <= 0" > > > > > > > Abort trap (core dumped) > > > > > > > sh /usr/src/release/scripts/make-manifest.sh *.txz > MANIFEST > > > > > > > > > > > > > > What causes this? Build machine is a 2x4-core Intel box with ZFS > > > > > > > file-systems all around. I tried stopping NTPD temporarily but the failures > > > > > > > persist .. sometimes :-( > > > > > > > > > > > > > > I've seen this at different points in the archiving process so it doesn't > > > > > > > seem specific to building kernel.txz. > > > > > > > > > > > > What timecounter do you use? Perhaps show the whole output from > > > > > > sysctl kern.timecounter. > > > > > > > > > > imb@vm01:/home/imb> sysctl kern.timecounter > > > > > kern.timecounter.tsc_shift: 1 > > > > > kern.timecounter.smp_tsc_adjust: 0 > > > > > kern.timecounter.smp_tsc: 1 > > > > > kern.timecounter.invariant_tsc: 1 > > > > > kern.timecounter.fast_gettime: 1 > > > > > kern.timecounter.tick: 1 > > > > > kern.timecounter.choice: ACPI-fast(900) HPET(950) i8254(0) TSC-low(1000) > > > > > dummy(-1000000) > > > > > kern.timecounter.hardware: HPET > > > > > kern.timecounter.alloweddeviation: 5 > > > > > kern.timecounter.timehands_count: 2 > > > > > kern.timecounter.stepwarnings: 0 > > > > > kern.timecounter.tc.ACPI-fast.quality: 900 > > > > > kern.timecounter.tc.ACPI-fast.frequency: 3579545 > > > > > kern.timecounter.tc.ACPI-fast.counter: 16124892 > > > > > kern.timecounter.tc.ACPI-fast.mask: 16777215 > > > > > kern.timecounter.tc.HPET.quality: 950 > > > > > kern.timecounter.tc.HPET.frequency: 14318180 > > > > > kern.timecounter.tc.HPET.counter: 1883995229 > > > > > kern.timecounter.tc.HPET.mask: 4294967295 > > > > > kern.timecounter.tc.i8254.quality: 0 > > > > > kern.timecounter.tc.i8254.frequency: 1193182 > > > > > kern.timecounter.tc.i8254.counter: 57 > > > > > kern.timecounter.tc.i8254.mask: 65535 > > > > > kern.timecounter.tc.TSC-low.quality: 1000 > > > > > kern.timecounter.tc.TSC-low.frequency: 1413153007 > > > > > kern.timecounter.tc.TSC-low.counter: 2352002295 > > > > > kern.timecounter.tc.TSC-low.mask: 4294967295 > > > > > > > > > > I overrode the default selection of counter-type as NTPD drifted so > > > > > badly as to require stepping almost hourly :-( > > > > If you return to TSC, does the problem go away? > > Same question if you leave HPET on, but set fast_gettime to 0. > > While I've only done one build (still) with HPET with > kern.timecounter.fast_gettime=0, I didn't see a core-dump. > I'll test more over the weekend, It is still not definitive, could you also run with timecounter set to TSC and fast_gettime=1? (Ignoring the ntpd or stopping it) From nobody Sat Oct 9 20:59:25 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 1F59D17EBB92 for ; Sat, 9 Oct 2021 20:59:44 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vk1-xa31.google.com (mail-vk1-xa31.google.com [IPv6:2607:f8b0:4864:20::a31]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature 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 4HRcrH6styz4gWq for ; Sat, 9 Oct 2021 20:59:43 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vk1-xa31.google.com with SMTP id f126so5696076vke.3 for ; Sat, 09 Oct 2021 13:59:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=13wIW+ytjsAd5+yoCdUKWWSCr2XsJxKq5WhcaW7BviI=; b=n8hF6gRxi7f0B8OafykjqHPJoQwrEEoav9Bq5WsLVMMWqfS3tS4tHdVa4TL/dAjrG0 ckCsLIC/R0KJxo6t00qZkT8OR4koEF4zsy4Uo630MsRBtdMDmM2s07x4Sf4ixDHJI2WH 7KbdGX6IIbS6HXTTNw9UwWL3qVVhfmKcAIzywK8efQPxTXirVRlFgFmfltMJEfFCDMtj mmuA4jT4b8/Y7iQ+T2AdgD6K5PCQbs7PvcOvVzDTVlRBNJmkmqgd+GthOiP+uGioPy2n s7DVlt8IMzp6qjaU9zqLKlvrjqJbAGZfc6OX8CIQDxCRfhIcwUiwewcPJWM3Q8mDQ4db 0TzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=13wIW+ytjsAd5+yoCdUKWWSCr2XsJxKq5WhcaW7BviI=; b=rrtWTIW01t0h4HHO5MWsY0z6oh1K8kKYtPGr+Xaqe4BwprLqmGLRK9GaXaYOLXFaOu by/RGq+EeE7nouqYUlqvGQ/hMXRJ5/yiUEkUXV9sdN1xkJyZ21S2p1PDyzbYH/A1ntLt 1VZjVl5whClYS4GPV28B+e99JjV/eUgcRXuu4UDohZXz8BmBKb5VbDKPz3dVQJEJv3ny DGC+aYoSUu2Aul5C+e/UFibJ0g+qGY8zaD4K84pGEaw91bBcqonwlGGN3+ugo0YoyyPi eITIsjag9rq8kF3Z/qaR75xwyyk49HGxhLRdcdY60CmZmoeoIqcnORf69UuPZwmatz5I f3oQ== X-Gm-Message-State: AOAM533uz7U6f5Awe7hpQbN6JDi98AKDV74VA7CgnZxSVIwA85XBGlWE CuWwrFS+Rvi+fCkj7NTf1cQtK7k61MRAatlZf1W2FZuF/Yk= X-Google-Smtp-Source: ABdhPJyv0E+Uk9eCXFe01MMTWU0klcbC1SrxYnHdpIZm7ukHESbnwHLKnB11DTFM0XjdDtISWqeIrzZYkWYpNvjYrWo= X-Received: by 2002:a1f:2f54:: with SMTP id v81mr15339246vkv.21.1633813176699; Sat, 09 Oct 2021 13:59:36 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Sat, 9 Oct 2021 14:59:25 -0600 Message-ID: Subject: Re: Dell Latitude 7400 - nvme0: Missing interrupt To: Pavel Timofeev Cc: Chuck Tuffli , freebsd-current Content-Type: multipart/alternative; boundary="00000000000006dea205cdf1c69d" X-Rspamd-Queue-Id: 4HRcrH6styz4gWq X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --00000000000006dea205cdf1c69d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Oct 9, 2021, 8:44 AM Pavel Timofeev wrote: > > > =D0=BF=D1=82, 8 =D0=BE=D0=BA=D1=82. 2021 =D0=B3. =D0=B2 14:49, Warner Los= h : > >> >> >> On Fri, Oct 8, 2021 at 2:42 PM Pavel Timofeev wrote: >> >>> >>> >>> =D1=81=D0=B1, 21 =D0=B0=D0=B2=D0=B3. 2021 =D0=B3. =D0=B2 15:22, Warner = Losh : >>> >>>> >>>> >>>> On Sat, Aug 21, 2021 at 3:06 PM Pavel Timofeev >>>> wrote: >>>> >>>>> >>>>> >>>>> Warner Losh : >>>>> >>>>>> >>>>>> >>>>>> On Fri, Aug 20, 2021 at 10:42 PM Pavel Timofeev >>>>>> wrote: >>>>>> >>>>>>> Pavel Timofeev : >>>>>>> >>>>>>> > >>>>>>> > Chuck Tuffli : >>>>>>> > >>>>>>> >> On Mon, Aug 16, 2021 at 7:43 PM Pavel Timofeev >>>>>>> wrote: >>>>>>> >> > >>>>>>> >> > Hello >>>>>>> >> > I've got a Dell Latitude 7400 and tried installing the latest >>>>>>> >> 14.0-CURRENT >>>>>>> >> > (main-n248636-d20e9e02db3) on it. >>>>>>> >> > Despite other things the weird one which concerns me is >>>>>>> >> > nvme0: Missing interrupt >>>>>>> >> > message I get sometimes on the console. >>>>>>> >> > It seems like I get it only after the reboot of the laptop, i. >>>>>>> e. not >>>>>>> >> > getting that message if I power cycle the laptop, at least I >>>>>>> haven't >>>>>>> >> seen >>>>>>> >> > them for now in such cases. >>>>>>> >> > So when the laptop is rebooted I can't even take advantage of >>>>>>> >> > nvmecontrol(8) quickly. >>>>>>> >> > Well, it still works, but it takes tens of seconds to return >>>>>>> the output. >>>>>>> >> ... >>>>>>> >> > dmesg when power cycled - >>>>>>> >> > >>>>>>> https://drive.google.com/file/d/1dB27oB1O2CcnZy6DvOOhmFO8SN8V8SwJ >>>>>>> >> > dmesg when rebooted - >>>>>>> >> > >>>>>>> https://drive.google.com/file/d/1DsKTMkihp_OmUcirByLaVO4o2mU38Bxh >>>>>>> >> >>>>>>> >> I'm sort of curious about the time stamps for the log messages i= n >>>>>>> the >>>>>>> >> failing case. Something like: >>>>>>> >> >>>>>>> >> $ grep "nv\(me\|d\)" /var/log/messages >>>>>>> >> >>>>>>> >> --chuck >>>>>>> >> >>>>>>> > >>>>>>> > Well, I can't see timestamps in the verbose boot log. Am I missin= g >>>>>>> some >>>>>>> > configuration for that? >>>>>>> > >>>>>>> > $ grep "nv\(me\|d\)" /var/log/messages >>>>>>> > nvme0: mem >>>>>>> > 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff >>>>>>> at device >>>>>>> > 0.0 on pci6 >>>>>>> > nvme0: attempting to allocate 5 MSI-X vectors (17 supported) >>>>>>> > nvme0: using IRQs 133-137 for MSI-X >>>>>>> > nvme0: CapLo: 0x140103ff: MQES 1023, CQR, TO 20 >>>>>>> > nvme0: CapHi: 0x00000030: DSTRD 0, NSSRS, CSS 1, MPSMIN 0, MPSMAX= 0 >>>>>>> > nvme0: Version: 0x00010300: 1.3 >>>>>>> > nvme0: Missing interrupt >>>>>>> > nvme0: Missing interrupt >>>>>>> > nvme0: Missing interrupt >>>>>>> > nvme0: Missing interrupt >>>>>>> > nvme0: Missing interrupt >>>>>>> > nvme0: Missing interrupt >>>>>>> > nvme0: Missing interrupt >>>>>>> > nvme0: Missing interrupt >>>>>>> > nvme0: Missing interrupt >>>>>>> > nvme0: Missing interrupt >>>>>>> > nvme0: Missing interrupt >>>>>>> > nvme0: Missing interrupt >>>>>>> > nvd0: NVMe namespace >>>>>>> > GEOM: new disk nvd0 >>>>>>> > nvd0: 488386MB (1000215216 512 byte sectors) >>>>>>> > >>>>>>> >>>>>>> >>>>>>> Ah, sorry, provided wrong output. >>>>>>> Here is what you requested: >>>>>>> $ grep "nv\(me\|d\)" /var/log/messages >>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: mem >>>>>>> 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff a= t >>>>>>> device >>>>>>> 0.0 on pci6 >>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: attempting to allocate 5 >>>>>>> MSI-X >>>>>>> vectors (17 supported) >>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: using IRQs 133-137 for MSI-= X >>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: CapLo: 0x140103ff: MQES >>>>>>> 1023, CQR, >>>>>>> TO 20 >>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: CapHi: 0x00000030: DSTRD 0, >>>>>>> NSSRS, >>>>>>> CSS 1, MPSMIN 0, MPSMAX 0 >>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: Version: 0x00010300: 1.3 >>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: Missing interrupt >>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: Missing interrupt >>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: Missing interrupt >>>>>>> Aug 21 04:34:36 nostromo kernel: nvd0: >>>>>>> NVMe >>>>>>> namespace >>>>>>> Aug 21 04:34:36 nostromo kernel: GEOM: new disk nvd0 >>>>>>> Aug 21 04:34:36 nostromo kernel: nvd0: 488386MB (1000215216 512 byt= e >>>>>>> sectors) >>>>>>> Aug 21 04:34:42 nostromo kernel: nvme0: Missing interrupt >>>>>>> Aug 21 04:35:36 nostromo kernel: nvme0: Missing interrupt >>>>>>> Aug 21 04:35:50 nostromo kernel: nvme0: Missing interrupt >>>>>>> >>>>>> >>>>>> What happens if you set hw.nvme.use_nvd=3D0 and hw.cam.nda.nvd_compa= t=3D1 >>>>>> in the boot loader and reboot? Same thing except nda where nvd was? >>>>>> Or does >>>>>> it work? >>>>>> >>>>>> Something weird is going on in the interrupt assignment, I think, bu= t >>>>>> I >>>>>> wanted to get any nvd vs nda issues out of the way first. >>>>>> >>>>>> Warner >>>>>> >>>>> >>>>> Do you mean kern.cam.nda.nvd_compat instead of hw.cam.nda.nvd_compat? >>>>> kern.cam.nda.nvd_compat is 1 by default now. >>>>> >>>>> So I tried to set hw.nvme.use_nvd to 1 as suggested, but I still see >>>>> nvme0: Missing interrupt >>>>> and now also >>>>> Root mount waiting for: CAM >>>>> messages besides those >>>>> >>>> >>>> OK. That all makes sense. I'd forgotten that nvd_compat=3D1 by default >>>> these >>>> days. >>>> >>>> I'll take a look on monday starting at the differences in interrupt >>>> assignment that >>>> are apparent when you cold boot vs reboot. >>>> >>>> Thanks for checking... I'd hoped this was a cheap fix, but also didn't >>>> really >>>> expect it to be. >>>> >>>> Warner >>>> >>>> >>> I've recently upgraded to main-n249974-17f790f49f5 and it got even wors= e >>> now. >>> So clean poweron works as before. >>> But if rebooted nvme drive refuses to work, while before the code >>> upgrade it was just complaining about missing interrupts. >>> >>> currently dmesg show this: >>> nvme0: mem >>> 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff at de= vice >>> 0.0 on pci6 >>> nvd0: NVMe namespace >>> nvd0: 488386MB (1000215216 512 byte sectors) >>> nvme0: mem >>> 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff at de= vice >>> 0.0 on pci6 >>> >> >> Why is this showing up twice? Or is everything above this line left over >> from the first, working boot? >> >> >>> nvme0: RECOVERY_START 9585870784 vs 9367036288 >>> nvme0: timeout with nothing complete, resetting >>> nvme0: Resetting controller due to a timeout. >>> nvme0: RECOVERY_WAITING >>> nvme0: resetting controller >>> nvme0: aborting outstanding admin command >>> nvme0: IDENTIFY (06) sqid:0 cid:15 nsid:0 cdw10:00000001 cdw11:00000000 >>> nvme0: ABORTED - BY REQUEST (00/07) sqid:0 cid:15 cdw0:0 >>> nvme0: nvme_identify_controller failed! >>> nvme0: waiting >>> >> >> Clearly something bad is going on with the drive here... We looked into >> the completion queues when we didn't get an interrupt and there was noth= ing >> complete there.... >> >> The only thing I can think of is that this means there's a phase error >> between the drive and the system. I recently removed a second reset and >> made it an option NVME_2X_RESET. Can you see if adding >> 'options NVME_2X_RESET' to your kernel config fixes this? >> >> Warner >> >> >>> nvme0: mem >>> 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff at de= vice >>> 0.0 on pci6 >>> nvme0: RECOVERY_START 9362778467 vs 9361830561 >>> nvme0: timeout with nothing complete, resetting >>> nvme0: Resetting controller due to a timeout. >>> nvme0: RECOVERY_WAITING >>> nvme0: resetting controller >>> nvme0: aborting outstanding admin command >>> nvme0: IDENTIFY (06) sqid:0 cid:15 nsid:0 cdw10:00000001 cdw11:00000000 >>> nvme0: ABORTED - BY REQUEST (00/07) sqid:0 cid:15 cdw0:0 >>> nvme0: nvme_identify_controller failed! >>> nvme0: waiting >>> >>> > > Sorry, it's showing twice due to multiple reboots. For one boot it's like= : > nvme0: mem > 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff at devi= ce > 0.0 on pci6 > nvme0: RECOVERY_START 9633303481 vs 9365971423 > nvme0: timeout with nothing complete, resetting > nvme0: Resetting controller due to a timeout. > nvme0: RECOVERY_WAITING > nvme0: resetting controller > nvme0: aborting outstanding admin command > nvme0: IDENTIFY (06) sqid:0 cid:15 nsid:0 cdw10:00000001 cdw11:00000000 > nvme0: ABORTED - BY REQUEST (00/07) sqid:0 cid:15 cdw0:0 > nvme0: nvme_identify_controller failed! > nvme0: waiting > > Well, neither Windows not Linux have any problems with the device. I > understand they may be hiding it or workaround somehow. > Yea, I'm trying to figure out why your machine is different than mine, and what Windows or Linux do that is different. It may be dodgy hardware, but others have no trouble... I'll try setting NVME_2X_RESET in the kernel config and report back in a > while. > Thanks. If it helps, that tells me something. If it doesn't, that tells me something else. I suspect that it is somewhere else in the system, tbh, but I need to find it systematically. Warner > --00000000000006dea205cdf1c69d-- From nobody Sat Oct 9 22:27:53 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id BB8F417F6E35 for ; Sat, 9 Oct 2021 22:28:01 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670085.outbound.protection.outlook.com [40.107.67.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HRfp852xdz4t4r for ; Sat, 9 Oct 2021 22:28:00 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lGU9805oGoo+g/Lpi++QouOnDDsUi65wSYs0HAKsB/CUmt/tWogvlFN5j6Eg8vbBVaRZLC6Wd24JmrYKHWbWMZK9IndqXgGFEy2eB5RIofWw9rhzdtj46tFq10f2Mp72dqhwkvmpRTXXTSV+fZBTqmPXdTwKRLX1yrfYCO1RdO4VLUTA/2TwrLNdHotM4RbRfGf9C5ePZ+wEkC3o4kNYIuL6T1u+7/tTMxn/7T3GwBOdG3oJG2bPWi1J4rSHuZA4lBkNn+Iz+PNK/d456SsvesS86FVcVOiXRN2SlakJu2uD2bQ3IXpVfXMvDOPAS9OYadMfMKa3mhodj8EMLxs83A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=zzkeDZiN83FO7gxvy9V/g8ETJgh64Ff7O8W0JOdrhTw=; b=Uo+02ca3HRsVxfPIOladqlXDI/hBDolVBktm8TtwN3RN4TurEy++H/+Vq3SfWPHjUTu/wNcYj/VFuRs0RmVWxl3FZhwzeOSF5MFwwcuqTtfvuzcg9oWKx2gTXst1P7kaOAAlZu04SR/TVJG6cY9WMDyk8kwv8CkUc6WJ2nXHdfUGCHSc6YwR3WRYpLvizzTvXMA6VfBqzh2O1rHoK7TJ9+FPv6jw2ry747WQPQ/tXElw5vK5yC7UGuKbUNPrCgS2HNW22ZyOeZ06yt8t3GbJzM7zm5zYSfsuJrk7D5CDxrdOXjEFGC0QwDjs3YBTbEw7LQ4K9JlL8KK7A34wMNUzEg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zzkeDZiN83FO7gxvy9V/g8ETJgh64Ff7O8W0JOdrhTw=; b=TxhrEFZyjBAhtpnqgUQDj4nmO9dU8LKJNLvJbWKDQaYY1knJ0qjmoVXNWRAoiZSpwl10IOfDVyCc0kVKOZdYPcdTNFsa3S9UyhczGlat1Kj5ng50J4QG8E61J+pHJPMWLih3ywIAqoWxaV3w3zHnmqQn4bPpqUcTV/2yoS3l7+6L54zNHfHGpSgDddIfpQ6k5weh4xVOmZEn0ydumOeEuDut7FeoAbyq5oJcLJBbl5EigvcIeJMQ/mpm77WDX7YA6yijAQpY1B67mcAXkq4y92nFl+L4aB4VP9ARhRazAP/dEdjj2/5FjHho5q0cCIsE11jHfQ435RQgRmBg7/bPdQ== Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:19::29) by YQBPR0101MB6489.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c01:48::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.22; Sat, 9 Oct 2021 22:27:53 +0000 Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::7091:13ac:171f:1c12]) by YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::7091:13ac:171f:1c12%5]) with mapi id 15.20.4587.024; Sat, 9 Oct 2021 22:27:53 +0000 From: Rick Macklem To: "freebsd-current@freebsd.org" Subject: Re: Writing large build logs to NFS extremely slow? Thread-Topic: Writing large build logs to NFS extremely slow? Thread-Index: AQHXvRjIhXhFzFqRLESM9Us/FueWtqvKyjubgAAGXICAAAQr+YAAA4KvgABmJrg= Date: Sat, 9 Oct 2021 22:27:53 +0000 Message-ID: References: <20211007021643.bwglyvrswk2nm3fl@nexus.home.palmen-it.de> <20211009141852.3cmjh7tysnehum7b@nexus.home.palmen-it.de> <20211009155033.fckg4i7zqo4yt2te@nexus.home.palmen-it.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: 9807a5e2-285a-5f0c-1e6a-ee472d85c5d3 x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9e68998f-3928-4a50-cfa7-08d98b740903 x-ms-traffictypediagnostic: YQBPR0101MB6489: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: N0VyJ7jyFVHId0bX+SR+2nXeXw6w2i5hFuOqbfWDBjnwrgIsMvNCEuL0S07DhKjDHBB4izziOvD/mq4oeh0+q1elsR1veLtQ8No58J6o6P+c2+zMrDDj9ts8NIStc/PUkxl7bE77B5EfQL/NaIGA278BpL6Jsirz3keZO+c8Sl3zqASD78w6Tf79ccP8/v/rX45Eh13bW5NpFAoOY1TlVf5H8FdaiRTTVzG7utYcJy0KIsmhY9Dj1xsw/GuGo3ZRbP7+Q/cDklxzogy2JcAwLWvFJl/sgFDIql3aU1DS/9awAOLT0Fss0pf/loLV60PVjfrRuSntJFuSBVDIvLtYnmpNNPQuY8B46oTQ6qv7yZ8j3nOOlGT0OkW6J82PX69+TuBSvKNOeDX88voMkEimCXLqgC1CvVvDcQF4OJFW+8lrbCnV00AIs06Hhj5xMhqbU14WzswLy9Qm02ip7djDx7G0QQuxQjxa3Q1DIIE8gnoy1djfSXCFUxoaRIjOSEuaQzttWOI60c3LjCRwuP1rfl3lTtqVsLuGIh6D98foyqIgvuMoQbBLCdEiu1s9tzHJxwSG0hYHZ65+sxPc+BPHsl4HffwRDqtlnezZhhZJFeohQTrX0oXv2/7GfdgWgVct7OhsAXt+Iu/Yhfj5hMTAMPQnGng7nq0+eNfaHz6fxSWsCgauh/yD+/SIr6lCbSK9DDBzeE8/bmRdbn9nTLu/g/S7TI8fJkplnCD+wggujKGCCS7Sivj3zUr4GpP8io5oz2k9doa4qQDJkl00TsJ7Rd55ZuPIv/GApIX2mHBV1MQ= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(366004)(91956017)(33656002)(76116006)(83380400001)(66556008)(64756008)(66446008)(66946007)(7696005)(66476007)(6916009)(122000001)(38100700002)(38070700005)(2940100002)(2906002)(508600001)(9686003)(86362001)(8676002)(8936002)(55016002)(52536014)(6506007)(966005)(5660300002)(186003)(71200400001)(316002)(786003);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?sbESGNNZAfpyTsR94rc+iM1XOGEPKrSaQg6KU2W2i/MPO8KrkgS6Ivjltp?= =?iso-8859-1?Q?MujaA0+143V+mKPv7OtJcJkdodErfvSs/m4rt/F9kKk7F1B2GjP6iiWX5p?= =?iso-8859-1?Q?tQhbI5A91llFCmlx/v8E2HaVS9yywYijep1wKZ7Al33pjePHK9qb9DpXYh?= =?iso-8859-1?Q?mrfFiUij7lS7CY2jHyMpA1q/0Ty98wraZg7Il28vbJYTZ6GjkHO20lOosv?= =?iso-8859-1?Q?cgavJX8d4iLhsHp+fE409BeNYAkQpSOcsjImwQYUneHRfBE0/zCNNKuq8r?= =?iso-8859-1?Q?B/zJRFGG1HICnRIwWJQ4mABczK5OCXXSkDzpT6yy4clFWVNTc5E7sGjvJn?= =?iso-8859-1?Q?iveM7+fAQOWwjldo7ite5ij/7GjDuRrAI0WcsWH83VzhTK3AcT0yfKQJmA?= =?iso-8859-1?Q?7OtgbTf6qap1cndFKyJoAFdau82XTZm3Fv6eG1hdVHkd68pvttWpKvks5z?= =?iso-8859-1?Q?tSfgyo7Yw1dSLlp2QktbbdksGvalPNPIVY7wDoXj5hNurczFbW9CFmnOY0?= =?iso-8859-1?Q?R+/8fazosdmhbnatvzZ7u/AmMoXgS6McQ2TU2wZkmuqZrHAd1nvNruCFVB?= =?iso-8859-1?Q?V3NgNkovIwuPULp3V1eu/TECbq5G38NM3lmMJc4COSgeV9QiZhN8fliZ5p?= =?iso-8859-1?Q?EFgBZv6hxXWdbcRhSkOTdqJy40DNAg2UMdPAmCjKCuY26N/sfksQWa6odZ?= =?iso-8859-1?Q?R8NArj3Gwdle7q6tkEDpLtpjAXWj376XHrT8eWeak+nAnPsOfnkTlSQsDg?= =?iso-8859-1?Q?gO7osANakQbF1J9h4wDksU0MJQfh05bBcsjaPnDvhBYgstdZAqEUq5kP5C?= =?iso-8859-1?Q?vpRekOBPm4thDu70WdOxavh6/VmBO6ePMF3kschZrmpENEv8TDDjXRr1Dh?= =?iso-8859-1?Q?i+Kej5dlBJRKFhGbRSWAmgQ/lFS0Et0IcvZj7ybV/9P3fFxcA4yKG8LD2m?= =?iso-8859-1?Q?+bI3WfUEoURYlWNDpyQtRLpvBpy5CoA+dDcKW5x3PfjT3F0QEUSKvLikmL?= =?iso-8859-1?Q?/URnqbULeOV6xAsyLLGSp7mPQx3QXHB2KKQJZ4g9KT7kMUlmKwZWGHR1ms?= =?iso-8859-1?Q?WgbSUNsbhEIhAHyHUp1J7iNhJDo/uXd3U7gSRHd9YxdXxMnF0v8LALpbsf?= =?iso-8859-1?Q?gOw9Jrc1LbJP4pkoYqOAi84aJij6ykYsmEdroH4RKfgBg4qYMLxTWVP9X4?= =?iso-8859-1?Q?5Mjwi10rG8nmvYzjJULsbYf2ZFeAY/w99Sv0V71TvcWumlJHlAsKHM7lyw?= =?iso-8859-1?Q?HAKUMfOzZ5C6A56pId6OzYrExe7VyCpIe8JEKKOC/jl5XNPNWa03RIZzUO?= =?iso-8859-1?Q?G7SiFieCei2oXYfi+k63NRYWtgSy7rLUI8VSlYUI2wndMYHGICzOh8+HLD?= =?iso-8859-1?Q?vpYE0XVRXJXdEEK9YL1diphf+ZIXA6Z40Mf2yCMWKRTayiR4CFyx28H/tD?= =?iso-8859-1?Q?RvR4iISrXkwXNb57?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 9e68998f-3928-4a50-cfa7-08d98b740903 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Oct 2021 22:27:53.2398 (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: Qqz0Jhh2EfqyUT3UgeMMRTiZ8EkxMQ/wAOgKVVPCHc3Dqza90JyXcymu8eKgzooWrgq60pTJwD+P/MFLXeEpLw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQBPR0101MB6489 X-Rspamd-Queue-Id: 4HRfp852xdz4t4r X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=uoguelph.ca header.s=selector2 header.b=TxhrEFZy; arc=pass ("microsoft.com:s=arcselector9901:i=1"); dmarc=pass (policy=none) header.from=uoguelph.ca; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.67.85 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-5.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector2]; FREEFALL_USER(0.00)[rmacklem]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; MIME_GOOD(-0.10)[text/plain]; NEURAL_HAM_LONG(-1.00)[-1.000]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[uoguelph.ca:+]; DMARC_POLICY_ALLOW(-0.50)[uoguelph.ca,none]; RCVD_IN_DNSWL_NONE(0.00)[40.107.67.85:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; TO_DN_EQ_ADDR_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US]; RCVD_TLS_LAST(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.67.85:from] X-ThisMailContainsUnwantedMimeParts: N Rick Macklem wrote:=0A= ?Felix Palmen wrote:=0A= [stuff snipped]=0A= >>Ok, thanks for the insight here! So maybe, I could have a look at=0A= >>poudriere's code? If I understand you correctly, keeping the file open=0A= >>and just issuing more write() calls wouldn't trigger that problem?=0A= >Nope, I don't think keeping the file open would help much.=0A= >However, if the file is opened with O_DIRECT, you could try setting=0A= ># sysctl vfs.nfs.nfs_directio_enable=3D1=0A= >in the NFS client machine.=0A= Oops, my bad..I for some reason was thinking you were using an NFSv3=0A= mount, but you didn't say. For NFSv4, repeated open/close of the same=0A= file will result in significant overhead. The official remedy for this woul= d=0A= be enabling delegations, but there were some significant issues with using= =0A= them that were only fixed recently, so you need a really up to date system= =0A= if you are going to enable delegations on the NFSv4 server.=0A= =0A= rick=0A= =0A= rick=0A= =0A= > You could try the "nocto" mount option, which might help, if the log file= =0A= > is being re-opened many times, but I doubt it will help.=0A= =0A= Well, I take any suggestion, so will try that as well and report back,=0A= thanks again!=0A= =0A= Side note, please don't CC/To me, I'm subscribed the list ;)=0A= =0A= --=0A= Dipl.-Inform. Felix Palmen ,.//..........=0A= {web} http://palmen-it.de {jabber} [see email] ,//palmen-it.de=0A= {pgp public key} http://palmen-it.de/pub.txt // """""""""""=0A= {pgp fingerprint} A891 3D55 5F2E 3A74 3965 B997 3EF2 8B0A BC02 DA2A=0A= =0A= =0A= From nobody Sat Oct 9 22:47:35 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 8830D12D14E8 for ; Sat, 9 Oct 2021 22:47:52 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vk1-xa2d.google.com (mail-vk1-xa2d.google.com [IPv6:2607:f8b0:4864:20::a2d]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HRgF42yJ2z4vb7 for ; Sat, 9 Oct 2021 22:47:52 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vk1-xa2d.google.com with SMTP id 17so1763050vkn.9 for ; Sat, 09 Oct 2021 15:47:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=n3MILKDNLzQy2GmDy9ODwgu7FhaHezLb194cyabOddw=; b=WR7TL4VElGboZOHPqweq5CSBH3MKDpaONlK5SdtruaAGOkY4OZfpVNGV0wY4p+guBi n3TdB8UTMdkz1GM+t5jFWE54MfnW2iEY/WxurHwaIz7Krh26Xz9Ui/v4XFkybZpW+Ma3 OYuuxw383+GPb2XFwGvzid2UcbE0uBh4AniddnbUxc9HJS2azv89IdNenp1Pn7gI1dfg Ti1FVxNAa+jIBukfsuewYiD5DqqZtRXeJnFC2f8haH89WWJAtz+k8k0/afBbAEbVW43h q2tyAaCq/JqEW7CXKPdCXkpQ4OLdl6KrsCiZxLFXfZILRgodGLsfSKM9OYGOdHkjdHas NK2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=n3MILKDNLzQy2GmDy9ODwgu7FhaHezLb194cyabOddw=; b=bZNzI/Z5mbWHYFbtXrjp2NcSaMN5UWXBNgUlCQZla6vcfZniyO3lKWV49S3Zsu+Rr2 txC4DyRl7GleNU5oT4oIy/3mqu15EdIh5K2GiIrOUgRm4ZgKIXrdXb5qc9E9fqNvIJGL jj2uLd4+gPys5i2QTHQH0rSOAWteB6avm+AeoePW8eKR6JIBm1keY5YsA5tTk5JkgY7I tqFPHLkpheP+hQHsBUJ9gex6Ktes8kekq8g+XEpiLT4swhihiBjl788FJBdbc7xCA3ko m7blYRG9YVdA6JIsw5anuokipQoA0KatPcr+BUln/HtBmvVWLpFouVyMYAgV5vltbRLV mZ/A== X-Gm-Message-State: AOAM533ZYzt9xHWbJO2WBtNEUrCG70M9AVliedKXc+gNPKqoD/Fv7aUW 83DQzhbXAh0bTkUKlXK6jrIBu3mIDQuIMDLm5lIShSomyyGvdw== X-Google-Smtp-Source: ABdhPJzfKfJC4h46CN/ci6Z6QBk33nsbmKcQDhOXSpydccTiWG6CPwkSeai7B+BK7jgZyUAwg33HtvZAhXaNNkmBFXQ= X-Received: by 2002:ac5:c21a:: with SMTP id m26mr15706258vkk.18.1633819666412; Sat, 09 Oct 2021 15:47:46 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <20211009094624.3f3cacc8@jelly.fritz.box> <2FCA108B-29E1-48EA-A8C7-BC621CC6F963@FreeBSD.org> <94E84785-8F8C-4E90-A437-929565F5C968@FreeBSD.org> In-Reply-To: <94E84785-8F8C-4E90-A437-929565F5C968@FreeBSD.org> From: Warner Losh Date: Sat, 9 Oct 2021 16:47:35 -0600 Message-ID: Subject: Re: clang/llvm-tblgen --- ld: error: undefined symbol: setupterm To: Dimitry Andric Cc: FreeBSD User , FreeBSD CURRENT , Baptiste Daroussin Content-Type: multipart/alternative; boundary="000000000000d8095205cdf3484c" X-Rspamd-Queue-Id: 4HRgF42yJ2z4vb7 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --000000000000d8095205cdf3484c Content-Type: text/plain; charset="UTF-8" On Sat, Oct 9, 2021 at 11:09 AM Dimitry Andric wrote: > On 9 Oct 2021, at 15:40, Warner Losh wrote: > > > > On Sat, Oct 9, 2021, 5:59 AM Dimitry Andric wrote: > > On 9 Oct 2021, at 13:37, Dimitry Andric wrote: > > > > > > On 9 Oct 2021, at 09:46, FreeBSD User wrote: > > >> > > >> On recent CURRENT (FreeBSD 14.0-CURRENT #2 main-n249971-0525ece3554e: > > >> Fri Oct 8 15:17:34 CEST 2021 amd64) building of an 13-STABLE based > > >> appliance failed very early in the build process of the 13-STABLE > > >> sources as shown below. 13-STABLE is most recent, since the sources > are > > >> fetched every time the build process is triggered. > > > ... > > >> > /pool/home/ohartmann/Projects/router/router/apu2c4/src/tools/install.sh > > >> -s -o root -g wheel -m 555 compile_et > > >> /pool/home/ohartmann/Projects/router/router/apu2 > > >> > c4/world/amd64/ALERICH_13-STABLE_amd64/pool/home/ohartmann/Projects/router/router/apu2c4/src/amd64.amd64/tmp/legacy/usr/bin/compile_et > > >> --- _bootstrap-tools-usr.bin/clang/llvm-tblgen --- ld: error: > undefined > > >> symbol: setupterm > > >>>>> referenced by Process.cpp > > >>>>> > Process.o:(llvm::sys::Process::FileDescriptorHasColors(int)) > > > > > > It is complaining about ncurses functions; it seems that even though > the link step gets -lncursesw added, it still is not able to find the > symbol: > > > > Okay, this is because recently on -CURRENT, libtinfow got split off from > > libncursesw: https://cgit.freebsd.org/src/commit/?id=396851c20aebd > > > > This affects such cross-builds obviously, and manually adding -ltinfow > > to the link command line makes it link correctly. > > > > However, the 396851c20aebd commit is probably not suitable for MFC'ing > > to stable/13. Maybe we need to put some kind of kludge in > > share/mk/src.libnames.mk for this, or in the top-level Makefile.inc1? > > > > Baptiste, any ideas? :) > > > > Add setupterm() to libegacy as a nop. > > That's not enough I think, it requires more ncurses functions than just > setupterm. And it actually calls them and checks the return values too, > IIRC. :) > int setupterm(const char *t, int fd, int *errptr) { return OK; } int tigetnum(const char *t) { return 0; } TERMINAL *set_curterm(TERMINAL *t) { return NULL; } int del_curterm(TERMINAL *t) { return OK; } should do the trick. I'll see just how crazy an idea this might be since we're trying to get the first stage tool to work on a -current host. the only thing that clang is really using is tigetnum to see if the terminal has color. Returning 0 tells it no. Or we could contrive, during bootstrap, to ensure that LLVM_ENABLE_TERMINFO is not defined. Nobody ever needs color error messages. They are nice to have, sure, but are not strictly needed if the alternative is monochrome error messages while building the system. There's already an ifdef protecting it: /* Define if the setupterm() function is supported this platform. */ #if defined(__FreeBSD__) /* * This is only needed for terminalHasColors(). When disabled LLVM falls back * to checking a list of TERM prefixes which is sufficient for a bootstrap tool. */ #define LLVM_ENABLE_TERMINFO 1 #endif It would be easy enough to add a && !defined(LLVM_BOOTSTRAP_BUILD) or similar. Warner --000000000000d8095205cdf3484c-- From nobody Sat Oct 9 23:11:41 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id CE6EF12D4153 for ; Sat, 9 Oct 2021 23:12:03 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: from mail-ed1-x52a.google.com (mail-ed1-x52a.google.com [IPv6:2a00:1450:4864:20::52a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HRgmz0wTRz3FGg for ; Sat, 9 Oct 2021 23:12:03 +0000 (UTC) (envelope-from zbeeble@gmail.com) Received: by mail-ed1-x52a.google.com with SMTP id t16so29086879eds.9 for ; Sat, 09 Oct 2021 16:12:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=49Ji+d3oha8QqoJi59xu/klzo0zimBiPCLzH/DKayis=; b=iFYagCa5C9TbwHWIufyMaS5q6lMUxsmheWVy+4h0xlyz/nK0eXUZSS7bd4IyHc467b gbWS9tbtcmsOgUCKp1v21Y3JxxHSuTZCnWJQJK6cgXUZVk/IBYZJVvNipSku70Ao7jt5 rRNCS8/o8WIXKVdSNd+FupMjcUmRdJivhAfvF0bXuemTYL1saUWvCZQ2TGxb3veWAX0H UjYBRhtVqVug4ZLcyeBCGBm7iRTBv4rKJcn2aNqFM5Ipw0Cv5O5hc81mzCmhqqn4d0uW fCvkfGNZIQ+iH/PJnV6S9GHAfx7S8oL5/M8S9heQn7E6XJPEmXjV2ZlT5PJGXSZUkdaz +8bA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=49Ji+d3oha8QqoJi59xu/klzo0zimBiPCLzH/DKayis=; b=J8yaaiusnwsg42VGupO1x8r3afES03Jq2uQtP5CkgofT/yzSUV1xcnzTE5C0DC8Hp5 zV9wAZk0SzQIOss/JT/O3yvIcUCL0VOexp595Y+Q/OjA5gEdCLXtxa8oGZrRzlAsAjvs zMyRSDBcUqnpqsQoC8gUavCArXBkT7U/9vEAPtS6jBQdf2AjJTgVfzhnJ2WvyPxHVTx0 ISz7fdAMNTLyM+PuLn2gF6as4OHEVPtKfRBojCT2VOELgIaRzEJbmRSuQmSeI0EOPbPn yr/x8ANh+3FaJTD9OcKWigGHSP0tMCKEu9DtHBRtq7LPrXg19yzejke2ORA3CasAQrnS i5AA== X-Gm-Message-State: AOAM530QWwGK5BEz4CQlBSfnR4R721mxkKEAyzY1FNV26ITz4Mc4nniz PHWNcAxkCY7ni8klwvF69yuZo/hxqcvlCFhE5G+6GKA= X-Google-Smtp-Source: ABdhPJxNqaJpnsIRno2XiXn5yJcFsfXcDwfkOSrCmvmAqqYTIbxxOcD0wNjhm5tI62581lwWoaSaE7RZaN5BnTkq/sQ= X-Received: by 2002:a05:6402:5c2:: with SMTP id n2mr27596122edx.239.1633821114860; Sat, 09 Oct 2021 16:11:54 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <20211007021643.bwglyvrswk2nm3fl@nexus.home.palmen-it.de> In-Reply-To: <20211007021643.bwglyvrswk2nm3fl@nexus.home.palmen-it.de> From: Zaphod Beeblebrox Date: Sat, 9 Oct 2021 19:11:41 -0400 Message-ID: Subject: Re: Writing large build logs to NFS extremely slow? To: freebsd-current Content-Type: multipart/alternative; boundary="0000000000002d878e05cdf39f94" X-Rspamd-Queue-Id: 4HRgmz0wTRz3FGg X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=iFYagCa5; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of zbeeble@gmail.com designates 2a00:1450:4864:20::52a as permitted sender) smtp.mailfrom=zbeeble@gmail.com X-Spamd-Result: default: False [-1.71 / 15.00]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; URI_COUNT_ODD(1.00)[1]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; SUBJECT_ENDS_QUESTION(1.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.88)[-0.884]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.83)[-0.826]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::52a:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: Y --0000000000002d878e05cdf39f94 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Is the NFS mounted filesystem NFS? I've found NFS mounted ZFS has several pathologies like this when there is no SSD cache and/or log vdevs attached. On Wed, Oct 6, 2021 at 10:18 PM Felix Palmen wrote: > Hi all, > > I use a -CURRENT bhyve vm for testing port builds with poudriere. As > this vm is only running when needed, but I want to always have access to > the build logs, I use NFS to mount /usr/local/poudriere/data/logs from > the host. > > I noticed some few ports take ridiculously long to build while barely > using any CPU time at all. On a closer look, that's all ports producing > a lot of compiler (warning) output, e.g. gcc, gnutls, gtk2, =E2=80=A6 > > So I assume appending to a large file via NFS gets slower and slower. Is > there any mount option I could try to fix this? Right now I only have > `nolockd`, I also tried `noncontigwr` which didn't change anything. > > Thinking about alternatives to NFS, are there any news for client-side > 9p virtfs? I found which > still builds with a few minor adaptions, but trying to mount a 9p share > freezes the machine. > > Would you suggest a different mailing list to ask? > > BR, Felix > > -- > Dipl.-Inform. Felix Palmen ,.//.......... > {web} http://palmen-it.de {jabber} [see email] ,//palmen-it.de > {pgp public key} http://palmen-it.de/pub.txt // """"""""""" > {pgp fingerprint} A891 3D55 5F2E 3A74 3965 B997 3EF2 8B0A BC02 DA2A > --0000000000002d878e05cdf39f94-- From nobody Sat Oct 9 23:15:11 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 617FB12D52E2 for ; Sat, 9 Oct 2021 23:15:22 +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 4HRgrn6cTJz3GQ9; Sat, 9 Oct 2021 23:15:21 +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 199NFBsL061562 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 10 Oct 2021 02:15:14 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 199NFBsL061562 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 199NFBL7061560; Sun, 10 Oct 2021 02:15:11 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 10 Oct 2021 02:15:11 +0300 From: Konstantin Belousov To: Warner Losh Cc: Dimitry Andric , FreeBSD User , FreeBSD CURRENT , Baptiste Daroussin Subject: Re: clang/llvm-tblgen --- ld: error: undefined symbol: setupterm Message-ID: References: <20211009094624.3f3cacc8@jelly.fritz.box> <2FCA108B-29E1-48EA-A8C7-BC621CC6F963@FreeBSD.org> <94E84785-8F8C-4E90-A437-929565F5C968@FreeBSD.org> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on tom.home X-Rspamd-Queue-Id: 4HRgrn6cTJz3GQ9 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Sat, Oct 09, 2021 at 04:47:35PM -0600, Warner Losh wrote: > On Sat, Oct 9, 2021 at 11:09 AM Dimitry Andric wrote: > > > On 9 Oct 2021, at 15:40, Warner Losh wrote: > > > > > > On Sat, Oct 9, 2021, 5:59 AM Dimitry Andric wrote: > > > On 9 Oct 2021, at 13:37, Dimitry Andric wrote: > > > > > > > > On 9 Oct 2021, at 09:46, FreeBSD User wrote: > > > >> > > > >> On recent CURRENT (FreeBSD 14.0-CURRENT #2 main-n249971-0525ece3554e: > > > >> Fri Oct 8 15:17:34 CEST 2021 amd64) building of an 13-STABLE based > > > >> appliance failed very early in the build process of the 13-STABLE > > > >> sources as shown below. 13-STABLE is most recent, since the sources > > are > > > >> fetched every time the build process is triggered. > > > > ... > > > >> > > /pool/home/ohartmann/Projects/router/router/apu2c4/src/tools/install.sh > > > >> -s -o root -g wheel -m 555 compile_et > > > >> /pool/home/ohartmann/Projects/router/router/apu2 > > > >> > > c4/world/amd64/ALERICH_13-STABLE_amd64/pool/home/ohartmann/Projects/router/router/apu2c4/src/amd64.amd64/tmp/legacy/usr/bin/compile_et > > > >> --- _bootstrap-tools-usr.bin/clang/llvm-tblgen --- ld: error: > > undefined > > > >> symbol: setupterm > > > >>>>> referenced by Process.cpp > > > >>>>> > > Process.o:(llvm::sys::Process::FileDescriptorHasColors(int)) > > > > > > > > It is complaining about ncurses functions; it seems that even though > > the link step gets -lncursesw added, it still is not able to find the > > symbol: > > > > > > Okay, this is because recently on -CURRENT, libtinfow got split off from > > > libncursesw: https://cgit.freebsd.org/src/commit/?id=396851c20aebd > > > > > > This affects such cross-builds obviously, and manually adding -ltinfow > > > to the link command line makes it link correctly. > > > > > > However, the 396851c20aebd commit is probably not suitable for MFC'ing > > > to stable/13. Maybe we need to put some kind of kludge in > > > share/mk/src.libnames.mk for this, or in the top-level Makefile.inc1? > > > > > > Baptiste, any ideas? :) > > > > > > Add setupterm() to libegacy as a nop. > > > > That's not enough I think, it requires more ncurses functions than just > > setupterm. And it actually calls them and checks the return values too, > > IIRC. :) > > > > int setupterm(const char *t, int fd, int *errptr) { return OK; } > int tigetnum(const char *t) { return 0; } > TERMINAL *set_curterm(TERMINAL *t) { return NULL; } > int del_curterm(TERMINAL *t) { return OK; } > > should do the trick. I'll see just how crazy an idea this might be > since we're trying to get the first stage tool to work on a -current > host. the only thing that clang is really using is tigetnum to see > if the terminal has color. Returning 0 tells it no. > > Or we could contrive, during bootstrap, to ensure that > LLVM_ENABLE_TERMINFO is not defined. Nobody ever needs > color error messages. They are nice to have, sure, but are not > strictly needed if the alternative is monochrome error messages > while building the system. There's already an ifdef protecting it: > > /* Define if the setupterm() function is supported this platform. */ > #if defined(__FreeBSD__) > /* > * This is only needed for terminalHasColors(). When disabled LLVM falls > back > * to checking a list of TERM prefixes which is sufficient for a bootstrap > tool. > */ > #define LLVM_ENABLE_TERMINFO 1 > #endif > > It would be easy enough to add a && !defined(LLVM_BOOTSTRAP_BUILD) > or similar. I do not quite understand how would it help. You need to add this to HEAD sources back in time, not to the current sources. From nobody Sat Oct 9 23:29:39 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 2348E12D73C2 for ; Sat, 9 Oct 2021 23:29:52 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vs1-xe2a.google.com (mail-vs1-xe2a.google.com [IPv6:2607:f8b0:4864:20::e2a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HRh9X0Ck1z3Hg4 for ; Sat, 9 Oct 2021 23:29:52 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vs1-xe2a.google.com with SMTP id p18so14598519vsu.7 for ; Sat, 09 Oct 2021 16:29:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rfk8kcaPYL5077oEz2oQZ5Gc2dDojovtsQo90wUTzgY=; b=Z0QnsG6fxoKqRu55y8FIDwX4OiK1FrobfZGAGDqa8AkI+0/YA+SumQvxcTf3/f0ZK4 GRhz309m35vytnnsqR+EiDjYC3JYm4aYIH354d0URyJ6gQz//IlVoSA2ZpINEJ1FVvZp VJvedlKTgI9ze1QXSyncOEM9JitWKwWA35YCQvkYxcSvzArIeFX60jHqMQ/PX0Oa+rCL h/0s7KtU+dlcFw+ADWyzclqcHPTiKKVo13ZNNF7XB9ALn5pnlnxKRwXPD0mP6UX5Bu2r vTdJSyAcs/y6IDFkajg57a3bHcqDIcNJ8c/Yyd3x7synwpIZGiUMqXWeKklca8cNcmzO 1+Vw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rfk8kcaPYL5077oEz2oQZ5Gc2dDojovtsQo90wUTzgY=; b=gBLs1cWLY1SXRx5u6y0465/Qq2ogeMf2KdiXBzSagLFaQPGrykeDQGRtqCjT61aRjG 6iIMzsVDF7SuAI9XIDMlfiuWwkS50U1v7OFO6G29iQjWr11tYqA7roQK7ZCaBtrDlPKO Rj91GY1o6QsO0wWhWf4wtmWTt/3Ajb2R3nNuCb9ig5qz/YxJJ5/GZ7MRJ+XHIyk0tCk6 6inSEyFGwQMLkRJCCpK01j/c1+eZHeN6kUJINgQ+vx0o3RivOrzrZwsPufXrlkaSlS5t kA/sAD0t2rmxix6WYk90lKxONFQ6/4VxxwQcnmcCRRg6cAR7VyF0kMjGRYqnihbemh/c /cNw== X-Gm-Message-State: AOAM532FQSyU9Z77poTxivw1JxhXNLygyZnty+U0pY1XjqU5xFeN52Wt ihyX3HXpddzYqBjLiaZncYWDWeKkGEFPwtCmu7rCGg== X-Google-Smtp-Source: ABdhPJzfpmfhdAyBVHGMAWET3v6gMI+XmEWzFhWW7Jlz71YBLe6h5VzI75dDJfyN49TZ21fHD1wT8sbEzp6kErz8hvw= X-Received: by 2002:a67:d28f:: with SMTP id z15mr18072155vsi.44.1633822191410; Sat, 09 Oct 2021 16:29:51 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <20211009094624.3f3cacc8@jelly.fritz.box> <2FCA108B-29E1-48EA-A8C7-BC621CC6F963@FreeBSD.org> <94E84785-8F8C-4E90-A437-929565F5C968@FreeBSD.org> In-Reply-To: From: Warner Losh Date: Sat, 9 Oct 2021 17:29:39 -0600 Message-ID: Subject: Re: clang/llvm-tblgen --- ld: error: undefined symbol: setupterm To: Konstantin Belousov Cc: Dimitry Andric , FreeBSD User , FreeBSD CURRENT , Baptiste Daroussin Content-Type: multipart/alternative; boundary="00000000000058795005cdf3df7f" X-Rspamd-Queue-Id: 4HRh9X0Ck1z3Hg4 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --00000000000058795005cdf3df7f Content-Type: text/plain; charset="UTF-8" On Sat, Oct 9, 2021, 5:15 PM Konstantin Belousov wrote: > On Sat, Oct 09, 2021 at 04:47:35PM -0600, Warner Losh wrote: > > On Sat, Oct 9, 2021 at 11:09 AM Dimitry Andric wrote: > > > > > On 9 Oct 2021, at 15:40, Warner Losh wrote: > > > > > > > > On Sat, Oct 9, 2021, 5:59 AM Dimitry Andric wrote: > > > > On 9 Oct 2021, at 13:37, Dimitry Andric wrote: > > > > > > > > > > On 9 Oct 2021, at 09:46, FreeBSD User > wrote: > > > > >> > > > > >> On recent CURRENT (FreeBSD 14.0-CURRENT #2 > main-n249971-0525ece3554e: > > > > >> Fri Oct 8 15:17:34 CEST 2021 amd64) building of an 13-STABLE > based > > > > >> appliance failed very early in the build process of the 13-STABLE > > > > >> sources as shown below. 13-STABLE is most recent, since the > sources > > > are > > > > >> fetched every time the build process is triggered. > > > > > ... > > > > >> > > > /pool/home/ohartmann/Projects/router/router/apu2c4/src/tools/install.sh > > > > >> -s -o root -g wheel -m 555 compile_et > > > > >> /pool/home/ohartmann/Projects/router/router/apu2 > > > > >> > > > > c4/world/amd64/ALERICH_13-STABLE_amd64/pool/home/ohartmann/Projects/router/router/apu2c4/src/amd64.amd64/tmp/legacy/usr/bin/compile_et > > > > >> --- _bootstrap-tools-usr.bin/clang/llvm-tblgen --- ld: error: > > > undefined > > > > >> symbol: setupterm > > > > >>>>> referenced by Process.cpp > > > > >>>>> > > > Process.o:(llvm::sys::Process::FileDescriptorHasColors(int)) > > > > > > > > > > It is complaining about ncurses functions; it seems that even > though > > > the link step gets -lncursesw added, it still is not able to find the > > > symbol: > > > > > > > > Okay, this is because recently on -CURRENT, libtinfow got split off > from > > > > libncursesw: https://cgit.freebsd.org/src/commit/?id=396851c20aebd > > > > > > > > This affects such cross-builds obviously, and manually adding > -ltinfow > > > > to the link command line makes it link correctly. > > > > > > > > However, the 396851c20aebd commit is probably not suitable for > MFC'ing > > > > to stable/13. Maybe we need to put some kind of kludge in > > > > share/mk/src.libnames.mk for this, or in the top-level > Makefile.inc1? > > > > > > > > Baptiste, any ideas? :) > > > > > > > > Add setupterm() to libegacy as a nop. > > > > > > That's not enough I think, it requires more ncurses functions than just > > > setupterm. And it actually calls them and checks the return values too, > > > IIRC. :) > > > > > > > int setupterm(const char *t, int fd, int *errptr) { return OK; } > > int tigetnum(const char *t) { return 0; } > > TERMINAL *set_curterm(TERMINAL *t) { return NULL; } > > int del_curterm(TERMINAL *t) { return OK; } > > > > should do the trick. I'll see just how crazy an idea this might be > > since we're trying to get the first stage tool to work on a -current > > host. the only thing that clang is really using is tigetnum to see > > if the terminal has color. Returning 0 tells it no. > > > > Or we could contrive, during bootstrap, to ensure that > > LLVM_ENABLE_TERMINFO is not defined. Nobody ever needs > > color error messages. They are nice to have, sure, but are not > > strictly needed if the alternative is monochrome error messages > > while building the system. There's already an ifdef protecting it: > > > > /* Define if the setupterm() function is supported this platform. */ > > #if defined(__FreeBSD__) > > /* > > * This is only needed for terminalHasColors(). When disabled LLVM falls > > back > > * to checking a list of TERM prefixes which is sufficient for a > bootstrap > > tool. > > */ > > #define LLVM_ENABLE_TERMINFO 1 > > #endif > > > > It would be easy enough to add a && !defined(LLVM_BOOTSTRAP_BUILD) > > or similar. > > I do not quite understand how would it help. > You need to add this to HEAD sources back in time, not to the current > sources. > Once merged, this would get stable building on current. But not older versions of stable, it is true. It's worth doing for that reason alone unless there's something clever we've not thought of yet with the current host. Warner > --00000000000058795005cdf3df7f-- From nobody Sat Oct 9 23:52:58 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 36F7612DC424 for ; Sat, 9 Oct 2021 23:53:07 +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 4HRhhL71Cbz3Nmh; Sat, 9 Oct 2021 23:53:06 +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 199Nqwj5071220 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Sun, 10 Oct 2021 02:53:01 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 199Nqwj5071220 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 199Nqwkk071219; Sun, 10 Oct 2021 02:52:58 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Sun, 10 Oct 2021 02:52:58 +0300 From: Konstantin Belousov To: Warner Losh Cc: Dimitry Andric , FreeBSD User , FreeBSD CURRENT , Baptiste Daroussin Subject: Re: clang/llvm-tblgen --- ld: error: undefined symbol: setupterm Message-ID: References: <20211009094624.3f3cacc8@jelly.fritz.box> <2FCA108B-29E1-48EA-A8C7-BC621CC6F963@FreeBSD.org> <94E84785-8F8C-4E90-A437-929565F5C968@FreeBSD.org> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on tom.home X-Rspamd-Queue-Id: 4HRhhL71Cbz3Nmh X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Sat, Oct 09, 2021 at 05:29:39PM -0600, Warner Losh wrote: > On Sat, Oct 9, 2021, 5:15 PM Konstantin Belousov > wrote: > > > On Sat, Oct 09, 2021 at 04:47:35PM -0600, Warner Losh wrote: > > > On Sat, Oct 9, 2021 at 11:09 AM Dimitry Andric wrote: > > > > > > > On 9 Oct 2021, at 15:40, Warner Losh wrote: > > > > > > > > > > On Sat, Oct 9, 2021, 5:59 AM Dimitry Andric wrote: > > > > > On 9 Oct 2021, at 13:37, Dimitry Andric wrote: > > > > > > > > > > > > On 9 Oct 2021, at 09:46, FreeBSD User > > wrote: > > > > > >> > > > > > >> On recent CURRENT (FreeBSD 14.0-CURRENT #2 > > main-n249971-0525ece3554e: > > > > > >> Fri Oct 8 15:17:34 CEST 2021 amd64) building of an 13-STABLE > > based > > > > > >> appliance failed very early in the build process of the 13-STABLE > > > > > >> sources as shown below. 13-STABLE is most recent, since the > > sources > > > > are > > > > > >> fetched every time the build process is triggered. > > > > > > ... > > > > > >> > > > > /pool/home/ohartmann/Projects/router/router/apu2c4/src/tools/install.sh > > > > > >> -s -o root -g wheel -m 555 compile_et > > > > > >> /pool/home/ohartmann/Projects/router/router/apu2 > > > > > >> > > > > > > c4/world/amd64/ALERICH_13-STABLE_amd64/pool/home/ohartmann/Projects/router/router/apu2c4/src/amd64.amd64/tmp/legacy/usr/bin/compile_et > > > > > >> --- _bootstrap-tools-usr.bin/clang/llvm-tblgen --- ld: error: > > > > undefined > > > > > >> symbol: setupterm > > > > > >>>>> referenced by Process.cpp > > > > > >>>>> > > > > Process.o:(llvm::sys::Process::FileDescriptorHasColors(int)) > > > > > > > > > > > > It is complaining about ncurses functions; it seems that even > > though > > > > the link step gets -lncursesw added, it still is not able to find the > > > > symbol: > > > > > > > > > > Okay, this is because recently on -CURRENT, libtinfow got split off > > from > > > > > libncursesw: https://cgit.freebsd.org/src/commit/?id=396851c20aebd > > > > > > > > > > This affects such cross-builds obviously, and manually adding > > -ltinfow > > > > > to the link command line makes it link correctly. > > > > > > > > > > However, the 396851c20aebd commit is probably not suitable for > > MFC'ing > > > > > to stable/13. Maybe we need to put some kind of kludge in > > > > > share/mk/src.libnames.mk for this, or in the top-level > > Makefile.inc1? > > > > > > > > > > Baptiste, any ideas? :) > > > > > > > > > > Add setupterm() to libegacy as a nop. > > > > > > > > That's not enough I think, it requires more ncurses functions than just > > > > setupterm. And it actually calls them and checks the return values too, > > > > IIRC. :) > > > > > > > > > > int setupterm(const char *t, int fd, int *errptr) { return OK; } > > > int tigetnum(const char *t) { return 0; } > > > TERMINAL *set_curterm(TERMINAL *t) { return NULL; } > > > int del_curterm(TERMINAL *t) { return OK; } > > > > > > should do the trick. I'll see just how crazy an idea this might be > > > since we're trying to get the first stage tool to work on a -current > > > host. the only thing that clang is really using is tigetnum to see > > > if the terminal has color. Returning 0 tells it no. > > > > > > Or we could contrive, during bootstrap, to ensure that > > > LLVM_ENABLE_TERMINFO is not defined. Nobody ever needs > > > color error messages. They are nice to have, sure, but are not > > > strictly needed if the alternative is monochrome error messages > > > while building the system. There's already an ifdef protecting it: > > > > > > /* Define if the setupterm() function is supported this platform. */ > > > #if defined(__FreeBSD__) > > > /* > > > * This is only needed for terminalHasColors(). When disabled LLVM falls > > > back > > > * to checking a list of TERM prefixes which is sufficient for a > > bootstrap > > > tool. > > > */ > > > #define LLVM_ENABLE_TERMINFO 1 > > > #endif > > > > > > It would be easy enough to add a && !defined(LLVM_BOOTSTRAP_BUILD) > > > or similar. > > > > I do not quite understand how would it help. > > You need to add this to HEAD sources back in time, not to the current > > sources. > > > > Once merged, this would get stable building on current. But not older > versions of stable, it is true. It's worth doing for that reason alone > unless there's something clever we've not thought of yet with the current > host. We can put somewhere a patch and add instructions how to use it to patch older HEADs and stable. May be instructions and the reference to the patch file should go into UPDATING 20211004 entry. From nobody Sun Oct 10 01:11:47 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 9EB7B17E3D2B for ; Sun, 10 Oct 2021 01:11:56 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-qb1can01on062d.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe5c::62d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HRkRH5wGCz3kDR for ; Sun, 10 Oct 2021 01:11:55 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OGusTLzvI+APGUeHhUkcBzcA0wsX52Wr5WzORTj7er4MgjQhd/ZyFZmyEdDopdaEY+U+kmtmCu2AF1yakd4l0Fkhv62D96f3uWphsvZzpauvXCFjmTNy1WJTBaT6bXXMqOXK8BA+O031kv2+wZhTxr0Ek87r64SWfCSr5QGOE8vL5QwsOSutTdDpaJNTMo/9CTuMyYpuBMzGnRdiA9L/E4IH+p/2wsNvryeF8n4zaN5321PjidnIFAckXkdX27XshT4Oiq1F8hPr3TMoyFD+/Vz22eQ1FMN8T890if9RCMNPX6fmCfiEbYE3pw4ERPZE2kw+oI/zFdCUfz8fsbT+dQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=OtkPKfiEL//G2sCPZZmFYZs0bSg4UqOEMHcRxlCi60s=; b=lM9zt9jiI0UEG9ONZ/an5mOtFIm19Y6Fhmf6OSiIvOO2QS+k95pjlZGH8C3howdhwWbrJtkIviBnyxCS6d1Q2kq1e/471aaQIVIPhxShDr5uZ3jplEHw66+B1syYKzfpLgIDCfbbMrs7GcVu/VrcndgDxE62TzVwZLayjjsEaO7rD37DlnKP1GOEmO6ExcUBPq3xy/Q2e2BOEIkd2YWKDyejJHiIAFz55gIQd2+P2B96TRltkKVH1odq0xFUjGsznc0aEtwYy2j1UN1GbKIrDlIBPlmZosn7bnXoGJ30M9Dp407bhF+1pbvdEq9YHGywRjuP9HkNvBlWshWJphjvRA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OtkPKfiEL//G2sCPZZmFYZs0bSg4UqOEMHcRxlCi60s=; b=bj23C06T7mQ+ClYw/rY+WWjNxe7Qr/fBA8MPxTtrqk2lTRIP62LrCXFtDvJHPq0EdK4YKUnpeozZvlDSvOKbmyZT9QYBWHvBsdOrKBuaA6Z3W8KGplPLn1m4R9pi23uz0EjgTampOxZYFNnnbMb6riyb0/2+0e9c2OhtMRSDePDwnlbp6Ru87l7MLqSlm7G5qwXgItW1QH8rnzrA4osYAgfKqwXPFjft7i0ydVKmchUPwXnXWK/qaGv/2VSyZ5Or8QeL0M3/tx9Pn6yKYpaahfSN/m/qvDaFemKH5618xIIe4V/Bt5FblsRmAU3At5IlNljWIG7VX1oa7IhLaLs2vQ== 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.4587.24; Sun, 10 Oct 2021 01:11:47 +0000 Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::7091:13ac:171f:1c12]) by YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::7091:13ac:171f:1c12%5]) with mapi id 15.20.4587.024; Sun, 10 Oct 2021 01:11:47 +0000 From: Rick Macklem To: FreeBSD Current Subject: RFC: Use of VOP_ALLOCATE() by NFSV4.2 nfsd Thread-Topic: RFC: Use of VOP_ALLOCATE() by NFSV4.2 nfsd Thread-Index: AQHXvXMbM0Hsf8N9W0qQA3mOobhhbw== Date: Sun, 10 Oct 2021 01:11:47 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: 2085c91e-3d9c-8215-2ddc-12b600b5e987 x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 365fe9a4-7810-4b96-acc4-08d98b8aee87 x-ms-traffictypediagnostic: YQBPR0101MB1761: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Oa+fchR1mZoHLU2J9euLEn8BgsRh9gnaa6eCHGeOr10ReXYDK+V82viEvjbXI7uEzYvKQlEnqwFIPeZ0ILNzkhnQNWmeNnwfWexU5AjSvV+f8LO77cKSWlrSnqAdkVUCI9Vq6xaJZ4Lgg/b/V3w38D4B55fctC5TMX+Zyk/G2UHNdVgcYaH/gEoFwFvyV8xGB2C3igYAAhbg1CMUxD3bE0Wfo5M2QTca9EvGCzyQN1wda2AtiqXju0ICsOJVcAuEf6DAgzg0GbqNB1pklk1weHEYmB9Wgn/ApW+zP8iEbWBOEzA9uoI+SBZLWanhblqnnzLsZzAOnzDdEvUf7gwai909mUV9RlBS33QFhjdTi4MFGkx3vPf9QSZj9v3nQaIRpJ62TvQZ5QccrIwOnKmh7CIBrdMvN+kZmCIMoCgqJLiGd9YmEwRp/Gnt7+huHpr5zaU0jcSpajjnJv6m+2G6z61PYRkWbljB2+YwWKhLVwhzMrXHi4oZYthxpNp2wwBz35nrsa+cmduX1hjP9HkVBeuX4DFxmLAHRXN2uUI2fk8Ro6mOfTXmQgQqeSxrIXENMjNooe9p+pvqx8/pxv7UEhghKmFOaVAca7cnElSMVJqa3t3QQrEXGE+y6OZsgpSvpRVWTFNYK7Ee2N12kHTAaLjNqoJPsVj0p+UtG9Mc/TnEyHZThqof4Fw/lvAU8BtecVttC+um1EhUKOoDX2ganw== x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(366004)(33656002)(786003)(66556008)(76116006)(7696005)(64756008)(66476007)(38100700002)(66946007)(4744005)(91956017)(66446008)(6916009)(6506007)(122000001)(8676002)(71200400001)(86362001)(186003)(2906002)(508600001)(9686003)(52536014)(8936002)(38070700005)(55016002)(316002)(5660300002);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?yX21Z5IBau1U9zEymiN0m3Gl3OHvlWa9y1zvZCfj4smPQcJJj9HpDcE3nc?= =?iso-8859-1?Q?nzmXQ0sosOR34fOBxRz2FWAaWKd70lzPtT8W3QvI9nGoPHsAqQe3kErvjk?= =?iso-8859-1?Q?QGA1E5cPYFIsj3WULPkx36xaQDsiQM/i6IAclumL9IuJtvUZXJ2xTgqsKu?= =?iso-8859-1?Q?ibE315VJKEX4xDJjDyIhAPabgcqMU6HqZp6qYLYHhkiQXsn7/dzbgI/r04?= =?iso-8859-1?Q?TGJGWOX0BFIGVxIHYGH/DXH3AzY57pcv5m/KdF5/OmrSX18GSBbb45Lu9e?= =?iso-8859-1?Q?HJtyGclqrc28v6Uc56mhEbXo9WAnTmHvS/FxwWkJ0y2DYQSyLnspkIt/1U?= =?iso-8859-1?Q?1B8NvtZoK84moUrzO4KwKLsyHCVL+vJ/HOuAFHW2H6HMWenU7SCfzqpeHg?= =?iso-8859-1?Q?Q8Xw5mQbhwgZsbGqil6BWqFPkwgidjIafJkO0xnmbQ7gqfBtAh97dBN+jz?= =?iso-8859-1?Q?jX3HTL1ow3dUWYEXJGCxANv0JtIqvydheix8+zeeS3D9LJ67E59rcHv8zr?= =?iso-8859-1?Q?xN1OpqT1NoimU5etghIX6DLOUONslSU5il/vlnukomql2fRhsQva7pcuqD?= =?iso-8859-1?Q?zy/4VOVyjMWfMm3oi9LqRxyUll8k+bxKsHgcUsCPR0EHeb3EuvlXv/C151?= =?iso-8859-1?Q?dU/I4qUaFoPPB5ZmuZHKUlzBbO5+yahY67QVMaiOboZSsRQiVJ+OlRk7T4?= =?iso-8859-1?Q?4G1TLt/2XLvoDpFr2dUZ6j8urQJ4FEONcAyLuGS3ESMEHUxADqf0BYy4Tc?= =?iso-8859-1?Q?A0xsauK2Y9UdOdPWjH51ZHQ5sVcVeOaxh4AU4esira46daL1mCNWjO1jfS?= =?iso-8859-1?Q?u+cSghF+sp0szgh2rRmCZWCkPH26m3icpBH4x4uhv077zeD5QkObpaeKLO?= =?iso-8859-1?Q?k0IffdWJkylV3FfBZc62luxlZIXmYzXxO27flGQA96CC24i6sOfV8xClPz?= =?iso-8859-1?Q?boKATO5JaGM/wJmGqcNS1H3ZANLV0nX1P/WaxwfAKDM9qCsb55IogfJylx?= =?iso-8859-1?Q?h+BhkRPpO1t6yUFdDkhjlecxTy2zicV3ssZCXZB2l/KAoolhPyuPMqZ7Yl?= =?iso-8859-1?Q?CdHAzKhXIB0UI7AQZElowtc8yC2afQCxrDgycLKgn1wClsRMxX0euiMVN1?= =?iso-8859-1?Q?Kh0PvMC7hLNRZfQtDXUW7SJD2PokDyEXEjCRi6qlCT4ml8JODzUjMcCLp+?= =?iso-8859-1?Q?6I5Zmvc7Wu/TgUghw0BWG47ESqp6RALRxssrWmMl3Zo02MPjClnTOKPXwx?= =?iso-8859-1?Q?jwURFgQcbqt3Zgvcq1CObqbemyAC4qNN6Pi/892j1Ea8Y+2Bm+ZrVvM574?= =?iso-8859-1?Q?igg8JVBKPUOtAei0h+ds8lQEvRrTjJzwEZpjrGCO8sswwe+dQ4U1Pqh78R?= =?iso-8859-1?Q?205zfFRrWdpj4ClFVBdQ5N63l6a0WJ2H5s9PSLFSGXha/BGIRGz9IvFxa2?= =?iso-8859-1?Q?8PjiXnuN5lfoyP1J?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 365fe9a4-7810-4b96-acc4-08d98b8aee87 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Oct 2021 01:11:47.2263 (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: E9mRGhEXhGy/clvZz0kjAwY5eYK050qKwTN3K34ReBiiKcc9nvNryXW/h55uQ3D2nbE/X0zhFPdT90qYL+FADQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQBPR0101MB1761 X-Rspamd-Queue-Id: 4HRkRH5wGCz3kDR X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=uoguelph.ca header.s=selector2 header.b=bj23C06T; arc=pass ("microsoft.com:s=arcselector9901:i=1"); dmarc=pass (policy=none) header.from=uoguelph.ca; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 2a01:111:f400:fe5c::62d as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-6.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector2]; FREEFALL_USER(0.00)[rmacklem]; FROM_HAS_DN(0.00)[]; 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]; DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[uoguelph.ca:+]; DMARC_POLICY_ALLOW(-0.50)[uoguelph.ca,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:8075, ipnet:2a01:111:f000::/36, country:US]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1] X-ThisMailContainsUnwantedMimeParts: N Hi,=0A= =0A= I ran into an issue this week during the nfsv4@ietf.org's testing event.=0A= UFS - supports VOP_ALLOCATE() by using vop_stdallocate().=0A= ZFS - just return EINVAL for VOP_ALLOCATE().=0A= =0A= An NFSv4.2 server can either support Allocate or not, but it has to be=0A= for all exported file systems.=0A= =0A= This leads me to a couple of questions:=0A= - Is there a good reason for not using vop_stdallocate() for ZFS?=0A= - Should I try and support both file system types via vop_stdallocate()=0A= or not support Allocate at all?=0A= =0A= Btw, as a bit of an aside, "cc" uses posix_fallocate() and in weird ways,= =0A= such as offset=3D0, len=3D1. Why, I have no idea?=0A= =0A= Thanks in advance for any comments, rick=0A= From nobody Sun Oct 10 03:52:11 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 05D3912D323A for ; Sun, 10 Oct 2021 03:52:29 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oi1-f182.google.com (mail-oi1-f182.google.com [209.85.167.182]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HRp0X5XDPz3vmC for ; Sun, 10 Oct 2021 03:52:28 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-oi1-f182.google.com with SMTP id y207so16295129oia.11 for ; Sat, 09 Oct 2021 20:52:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/+zo47dlabmOEht0Fs/tPJduvkd8Oz9Pwf2Mq5tT1d0=; b=eKTs8sBm6LycqonFyHVW7euO0c072JgSOx+wdxHUZkP32Z3tQCH/jci40ehklsJCru mZmKuqYDE+ixbHERvxBuMhYHqAPFuMOQjfXc/g1MnftI1/I3hY2DPFRcGPsFzD4iKxDO 3C339++RqW/k1/woJOOfn9QnyQPQsTswjgBc0SuhlNWYPp7SwFvnNTiCXiUMFAPabpMA igZqdNU3zNWnY3KqLew2W1Dbjj2kMbimD63q9hq5NmR9MBx+mC8NRmWU/O23eeA6Z5O2 /tfL8E4kK520+oPlmXkmaXAyedjN4el8E8/iF17nvPsdQ+E794a8GlPHdbh2MK8bewMZ NMRQ== X-Gm-Message-State: AOAM5335w3f9rouJw+Fp9GL3ER6qClZ7hpGcQRbsgLczd5wlEQFZye4M T7QOvIdI2a+NPotzjG31hufOqZ3vBNcs4zCYTTo3GxSr X-Google-Smtp-Source: ABdhPJw9+X0t7Xxf80HRA7vvO7LHh3FvyKKTGv4xXFaX2bylDlIRstNWO6BLILBQHVJJk/X53bv860jj5ndlB2ObZAM= X-Received: by 2002:a54:4f0e:: with SMTP id e14mr13905418oiy.73.1633837942076; Sat, 09 Oct 2021 20:52:22 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Alan Somers Date: Sat, 9 Oct 2021 21:52:11 -0600 Message-ID: Subject: Re: RFC: Use of VOP_ALLOCATE() by NFSV4.2 nfsd To: Rick Macklem Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4HRp0X5XDPz3vmC X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Sat, Oct 9, 2021 at 7:13 PM Rick Macklem wrote: > > Hi, > > I ran into an issue this week during the nfsv4@ietf.org's testing event. > UFS - supports VOP_ALLOCATE() by using vop_stdallocate(). > ZFS - just return EINVAL for VOP_ALLOCATE(). > > An NFSv4.2 server can either support Allocate or not, but it has to be > for all exported file systems. That seems like a protocol bug to me. Could this be fixed in a future NFS revision? > > This leads me to a couple of questions: > - Is there a good reason for not using vop_stdallocate() for ZFS? Yes. posix_fallocate is supposed to guarantee that subsequent writes to the file will not fail with ENOSPC. But ZFS, being a copy-on-write file system, cannot possibly guarantee that. See SVN r325320. > - Should I try and support both file system types via vop_stdallocate() > or not support Allocate at all? Since you can't possibly support it for ZFS (not to mention other file systems like fusefs) you'll have to not support it at all. > > Btw, as a bit of an aside, "cc" uses posix_fallocate() and in weird ways, > such as offset=0, len=1. Why, I have no idea? > > Thanks in advance for any comments, rick > From nobody Sun Oct 10 04:06:37 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0337512D4D71 for ; Sun, 10 Oct 2021 04:06:41 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HRpJw6K49z4RL7; Sun, 10 Oct 2021 04:06:40 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: from aniel.nours.eu (nours.eu [IPv6:2001:41d0:8:3a4d::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: bapt) by smtp.freebsd.org (Postfix) with ESMTPSA id 6F12727604; Sun, 10 Oct 2021 04:06:40 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: by aniel.nours.eu (Postfix, from userid 1001) id 84F1B60757; Sun, 10 Oct 2021 06:06:37 +0200 (CEST) Date: Sun, 10 Oct 2021 06:06:37 +0200 From: Baptiste Daroussin To: Konstantin Belousov Cc: Warner Losh , Dimitry Andric , FreeBSD User , FreeBSD CURRENT Subject: Re: clang/llvm-tblgen --- ld: error: undefined symbol: setupterm Message-ID: <20211010040637.3fw7q6nl7gn7aum4@aniel.nours.eu> References: <20211009094624.3f3cacc8@jelly.fritz.box> <2FCA108B-29E1-48EA-A8C7-BC621CC6F963@FreeBSD.org> <94E84785-8F8C-4E90-A437-929565F5C968@FreeBSD.org> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-ThisMailContainsUnwantedMimeParts: N On Sun, Oct 10, 2021 at 02:52:58AM +0300, Konstantin Belousov wrote: > On Sat, Oct 09, 2021 at 05:29:39PM -0600, Warner Losh wrote: > > On Sat, Oct 9, 2021, 5:15 PM Konstantin Belousov > > wrote: > > > > > On Sat, Oct 09, 2021 at 04:47:35PM -0600, Warner Losh wrote: > > > > On Sat, Oct 9, 2021 at 11:09 AM Dimitry Andric wrote: > > > > > > > > > On 9 Oct 2021, at 15:40, Warner Losh wrote: > > > > > > > > > > > > On Sat, Oct 9, 2021, 5:59 AM Dimitry Andric wrote: > > > > > > On 9 Oct 2021, at 13:37, Dimitry Andric wrote: > > > > > > > > > > > > > > On 9 Oct 2021, at 09:46, FreeBSD User > > > wrote: > > > > > > >> > > > > > > >> On recent CURRENT (FreeBSD 14.0-CURRENT #2 > > > main-n249971-0525ece3554e: > > > > > > >> Fri Oct 8 15:17:34 CEST 2021 amd64) building of an 13-STABLE > > > based > > > > > > >> appliance failed very early in the build process of the 13-STABLE > > > > > > >> sources as shown below. 13-STABLE is most recent, since the > > > sources > > > > > are > > > > > > >> fetched every time the build process is triggered. > > > > > > > ... > > > > > > >> > > > > > /pool/home/ohartmann/Projects/router/router/apu2c4/src/tools/install.sh > > > > > > >> -s -o root -g wheel -m 555 compile_et > > > > > > >> /pool/home/ohartmann/Projects/router/router/apu2 > > > > > > >> > > > > > > > > c4/world/amd64/ALERICH_13-STABLE_amd64/pool/home/ohartmann/Projects/router/router/apu2c4/src/amd64.amd64/tmp/legacy/usr/bin/compile_et > > > > > > >> --- _bootstrap-tools-usr.bin/clang/llvm-tblgen --- ld: error: > > > > > undefined > > > > > > >> symbol: setupterm > > > > > > >>>>> referenced by Process.cpp > > > > > > >>>>> > > > > > Process.o:(llvm::sys::Process::FileDescriptorHasColors(int)) > > > > > > > > > > > > > > It is complaining about ncurses functions; it seems that even > > > though > > > > > the link step gets -lncursesw added, it still is not able to find the > > > > > symbol: > > > > > > > > > > > > Okay, this is because recently on -CURRENT, libtinfow got split off > > > from > > > > > > libncursesw: https://cgit.freebsd.org/src/commit/?id=396851c20aebd > > > > > > > > > > > > This affects such cross-builds obviously, and manually adding > > > -ltinfow > > > > > > to the link command line makes it link correctly. > > > > > > > > > > > > However, the 396851c20aebd commit is probably not suitable for > > > MFC'ing > > > > > > to stable/13. Maybe we need to put some kind of kludge in > > > > > > share/mk/src.libnames.mk for this, or in the top-level > > > Makefile.inc1? > > > > > > > > > > > > Baptiste, any ideas? :) > > > > > > > > > > > > Add setupterm() to libegacy as a nop. > > > > > > > > > > That's not enough I think, it requires more ncurses functions than just > > > > > setupterm. And it actually calls them and checks the return values too, > > > > > IIRC. :) > > > > > > > > > > > > > int setupterm(const char *t, int fd, int *errptr) { return OK; } > > > > int tigetnum(const char *t) { return 0; } > > > > TERMINAL *set_curterm(TERMINAL *t) { return NULL; } > > > > int del_curterm(TERMINAL *t) { return OK; } > > > > > > > > should do the trick. I'll see just how crazy an idea this might be > > > > since we're trying to get the first stage tool to work on a -current > > > > host. the only thing that clang is really using is tigetnum to see > > > > if the terminal has color. Returning 0 tells it no. > > > > > > > > Or we could contrive, during bootstrap, to ensure that > > > > LLVM_ENABLE_TERMINFO is not defined. Nobody ever needs > > > > color error messages. They are nice to have, sure, but are not > > > > strictly needed if the alternative is monochrome error messages > > > > while building the system. There's already an ifdef protecting it: > > > > > > > > /* Define if the setupterm() function is supported this platform. */ > > > > #if defined(__FreeBSD__) > > > > /* > > > > * This is only needed for terminalHasColors(). When disabled LLVM falls > > > > back > > > > * to checking a list of TERM prefixes which is sufficient for a > > > bootstrap > > > > tool. > > > > */ > > > > #define LLVM_ENABLE_TERMINFO 1 > > > > #endif > > > > > > > > It would be easy enough to add a && !defined(LLVM_BOOTSTRAP_BUILD) > > > > or similar. > > > > > > I do not quite understand how would it help. > > > You need to add this to HEAD sources back in time, not to the current > > > sources. > > > > > > > Once merged, this would get stable building on current. But not older > > versions of stable, it is true. It's worth doing for that reason alone > > unless there's something clever we've not thought of yet with the current > > host. > > We can put somewhere a patch and add instructions how to use it to patch > older HEADs and stable. May be instructions and the reference to the patch > file should go into UPDATING 20211004 entry. It fails to link because the bootstrap tools are built statically if they were linked dynamically that would solve the situation, because libncursesw.so is a linkscript which does the right thing. Stupid question, why are bootstrap tools statically linked in the first place? If we remove -DNO_SHARED from the BARGS, it compiles perfectly fine. Imho we should remove the static linking here, the other way would be to provide a "flat" libncursesw.a for those cases on CURRENT. which I don't know how to provide without breaking things even more. Best regards, Bapt From nobody Sun Oct 10 04:41:11 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id D2A2A12DA606 for ; Sun, 10 Oct 2021 04:41:13 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HRq4n5Z5Pz4WnN; Sun, 10 Oct 2021 04:41:13 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: from aniel.nours.eu (nours.eu [IPv6:2001:41d0:8:3a4d::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: bapt) by smtp.freebsd.org (Postfix) with ESMTPSA id 6489A266BB; Sun, 10 Oct 2021 04:41:13 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: by aniel.nours.eu (Postfix, from userid 1001) id BEF4560AB5; Sun, 10 Oct 2021 06:41:11 +0200 (CEST) Date: Sun, 10 Oct 2021 06:41:11 +0200 From: Baptiste Daroussin To: Konstantin Belousov Cc: Warner Losh , Dimitry Andric , FreeBSD User , FreeBSD CURRENT Subject: Re: clang/llvm-tblgen --- ld: error: undefined symbol: setupterm Message-ID: <20211010044111.mvzuepff34ztqctq@aniel.nours.eu> References: <20211009094624.3f3cacc8@jelly.fritz.box> <2FCA108B-29E1-48EA-A8C7-BC621CC6F963@FreeBSD.org> <94E84785-8F8C-4E90-A437-929565F5C968@FreeBSD.org> <20211010040637.3fw7q6nl7gn7aum4@aniel.nours.eu> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20211010040637.3fw7q6nl7gn7aum4@aniel.nours.eu> X-ThisMailContainsUnwantedMimeParts: N On Sun, Oct 10, 2021 at 06:06:37AM +0200, Baptiste Daroussin wrote: > On Sun, Oct 10, 2021 at 02:52:58AM +0300, Konstantin Belousov wrote: > > On Sat, Oct 09, 2021 at 05:29:39PM -0600, Warner Losh wrote: > > > On Sat, Oct 9, 2021, 5:15 PM Konstantin Belousov > > > wrote: > > > > > > > On Sat, Oct 09, 2021 at 04:47:35PM -0600, Warner Losh wrote: > > > > > On Sat, Oct 9, 2021 at 11:09 AM Dimitry Andric wrote: > > > > > > > > > > > On 9 Oct 2021, at 15:40, Warner Losh wrote: > > > > > > > > > > > > > > On Sat, Oct 9, 2021, 5:59 AM Dimitry Andric wrote: > > > > > > > On 9 Oct 2021, at 13:37, Dimitry Andric wrote: > > > > > > > > > > > > > > > > On 9 Oct 2021, at 09:46, FreeBSD User > > > > wrote: > > > > > > > >> > > > > > > > >> On recent CURRENT (FreeBSD 14.0-CURRENT #2 > > > > main-n249971-0525ece3554e: > > > > > > > >> Fri Oct 8 15:17:34 CEST 2021 amd64) building of an 13-STABLE > > > > based > > > > > > > >> appliance failed very early in the build process of the 13-STABLE > > > > > > > >> sources as shown below. 13-STABLE is most recent, since the > > > > sources > > > > > > are > > > > > > > >> fetched every time the build process is triggered. > > > > > > > > ... > > > > > > > >> > > > > > > /pool/home/ohartmann/Projects/router/router/apu2c4/src/tools/install.sh > > > > > > > >> -s -o root -g wheel -m 555 compile_et > > > > > > > >> /pool/home/ohartmann/Projects/router/router/apu2 > > > > > > > >> > > > > > > > > > > c4/world/amd64/ALERICH_13-STABLE_amd64/pool/home/ohartmann/Projects/router/router/apu2c4/src/amd64.amd64/tmp/legacy/usr/bin/compile_et > > > > > > > >> --- _bootstrap-tools-usr.bin/clang/llvm-tblgen --- ld: error: > > > > > > undefined > > > > > > > >> symbol: setupterm > > > > > > > >>>>> referenced by Process.cpp > > > > > > > >>>>> > > > > > > Process.o:(llvm::sys::Process::FileDescriptorHasColors(int)) > > > > > > > > > > > > > > > > It is complaining about ncurses functions; it seems that even > > > > though > > > > > > the link step gets -lncursesw added, it still is not able to find the > > > > > > symbol: > > > > > > > > > > > > > > Okay, this is because recently on -CURRENT, libtinfow got split off > > > > from > > > > > > > libncursesw: https://cgit.freebsd.org/src/commit/?id=396851c20aebd > > > > > > > > > > > > > > This affects such cross-builds obviously, and manually adding > > > > -ltinfow > > > > > > > to the link command line makes it link correctly. > > > > > > > > > > > > > > However, the 396851c20aebd commit is probably not suitable for > > > > MFC'ing > > > > > > > to stable/13. Maybe we need to put some kind of kludge in > > > > > > > share/mk/src.libnames.mk for this, or in the top-level > > > > Makefile.inc1? > > > > > > > > > > > > > > Baptiste, any ideas? :) > > > > > > > > > > > > > > Add setupterm() to libegacy as a nop. > > > > > > > > > > > > That's not enough I think, it requires more ncurses functions than just > > > > > > setupterm. And it actually calls them and checks the return values too, > > > > > > IIRC. :) > > > > > > > > > > > > > > > > int setupterm(const char *t, int fd, int *errptr) { return OK; } > > > > > int tigetnum(const char *t) { return 0; } > > > > > TERMINAL *set_curterm(TERMINAL *t) { return NULL; } > > > > > int del_curterm(TERMINAL *t) { return OK; } > > > > > > > > > > should do the trick. I'll see just how crazy an idea this might be > > > > > since we're trying to get the first stage tool to work on a -current > > > > > host. the only thing that clang is really using is tigetnum to see > > > > > if the terminal has color. Returning 0 tells it no. > > > > > > > > > > Or we could contrive, during bootstrap, to ensure that > > > > > LLVM_ENABLE_TERMINFO is not defined. Nobody ever needs > > > > > color error messages. They are nice to have, sure, but are not > > > > > strictly needed if the alternative is monochrome error messages > > > > > while building the system. There's already an ifdef protecting it: > > > > > > > > > > /* Define if the setupterm() function is supported this platform. */ > > > > > #if defined(__FreeBSD__) > > > > > /* > > > > > * This is only needed for terminalHasColors(). When disabled LLVM falls > > > > > back > > > > > * to checking a list of TERM prefixes which is sufficient for a > > > > bootstrap > > > > > tool. > > > > > */ > > > > > #define LLVM_ENABLE_TERMINFO 1 > > > > > #endif > > > > > > > > > > It would be easy enough to add a && !defined(LLVM_BOOTSTRAP_BUILD) > > > > > or similar. > > > > > > > > I do not quite understand how would it help. > > > > You need to add this to HEAD sources back in time, not to the current > > > > sources. > > > > > > > > > > Once merged, this would get stable building on current. But not older > > > versions of stable, it is true. It's worth doing for that reason alone > > > unless there's something clever we've not thought of yet with the current > > > host. > > > > We can put somewhere a patch and add instructions how to use it to patch > > older HEADs and stable. May be instructions and the reference to the patch > > file should go into UPDATING 20211004 entry. > > It fails to link because the bootstrap tools are built statically if they were > linked dynamically that would solve the situation, because libncursesw.so is a > linkscript which does the right thing. > > Stupid question, why are bootstrap tools statically linked in the first place? > If we remove -DNO_SHARED from the BARGS, it compiles perfectly fine. > > Imho we should remove the static linking here, the other way would be to > provide a "flat" libncursesw.a for those cases on CURRENT. which I don't know how to > provide without breaking things even more. > > Best regards, > Bapt the reason being -DNO_SHARED is speeding up the bootstrap, so probably we need to either investigate make ncurses a bootstrap lib for clang, or having kind of an equivalent of what the linker script is doing for libncursesw.so but for libncursesw.a. Best regards, Bapt From nobody Sun Oct 10 04:41:30 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id E57EC12DA4E8 for ; Sun, 10 Oct 2021 04:41:40 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vs1-xe30.google.com (mail-vs1-xe30.google.com [IPv6:2607:f8b0:4864:20::e30]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HRq5J5QKnz4XJy for ; Sun, 10 Oct 2021 04:41:40 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vs1-xe30.google.com with SMTP id a10so4698726vsr.1 for ; Sat, 09 Oct 2021 21:41:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LWOwROqc5K94yjeow2cxdA4ZI6G3gL7/t5ZrLeabvWQ=; b=uCCoIJss7XDmrj7ljPKoRQ3GqQoOcJt2priqAoctaQYgZ9luHtAxkButVQ0LUZ05jD 2RqMZIE2HIvOX+kSqOsCBBbASj5NNMTlpKsaEbyuJEP9OVq3+KghBXL49Zp9p446OfNS n/17h9w/YPdcEezSfvjU8EoxRzvH20qeCWPpDwfVhwFmEGedwKKefgpxG+EYzrG+WC+N V/IhbyYlrwtGRwPLIdN01fN2erLxSIw+zB8qVCFa09tTY5/RaaqqXVCUGWXBzSLppK+F D5xWdlxyH48QC66O9VFeuGIQL1NGESvcKKT56/7BK4S2aazjep4WzcTIG7zaVgz1a2pR K+EA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LWOwROqc5K94yjeow2cxdA4ZI6G3gL7/t5ZrLeabvWQ=; b=MdLP90KHuGs7BizpFjvd/zcSDEtmpwiUG8v7DKrPQeecxe0HeyTn3A6DV2bW8aOSsb cd+Vpad7OxYy1YcV66zWz6HM+e9JHiVjYPn+YYeA2LOqda7ncoNSmWyTXTwKSFr/0AII e3OOE259kM6/BI0/bwAj0lf0L2hQPOK/l91Q+b6MU94j2Gsx9K7Kcc09uoLO9qcl2Cxo TpyUBOW8O0zrTOb7UbhdfJDmKsP4RXH76U8disObuKt1UaJYIlnG1s09bYV0EpmW9vsc K1e4rbGZI4bXwA+LbqCws0JGTPk4Erz31PvyX4ygGjDg8qPgN1XNAGYGDuctIQcFMDH9 55xQ== X-Gm-Message-State: AOAM532SHl3ebvWPNUHQBQjuiINrjAR24jm1MURFIZjBTumQQ0ElBlmF dvUtZTS+JKmx5y9BsQ+hdl0rJ9bTZfPL4AwitBgm3g== X-Google-Smtp-Source: ABdhPJxcn4YPTin+2MHn8kLTpKn0VvkhyKfqNBM0F3rKsabCftVsOpabgtMmYwLbmtkuJBNwr1tnDVsSv+W/L9l0HaI= X-Received: by 2002:a67:d28f:: with SMTP id z15mr18459848vsi.44.1633840894130; Sat, 09 Oct 2021 21:41:34 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <20211009094624.3f3cacc8@jelly.fritz.box> <2FCA108B-29E1-48EA-A8C7-BC621CC6F963@FreeBSD.org> <94E84785-8F8C-4E90-A437-929565F5C968@FreeBSD.org> <20211010040637.3fw7q6nl7gn7aum4@aniel.nours.eu> In-Reply-To: <20211010040637.3fw7q6nl7gn7aum4@aniel.nours.eu> From: Warner Losh Date: Sat, 9 Oct 2021 22:41:30 -0600 Message-ID: Subject: Re: clang/llvm-tblgen --- ld: error: undefined symbol: setupterm To: Baptiste Daroussin Cc: Konstantin Belousov , Dimitry Andric , FreeBSD User , FreeBSD CURRENT Content-Type: multipart/alternative; boundary="0000000000001d601e05cdf83ae8" X-Rspamd-Queue-Id: 4HRq5J5QKnz4XJy X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --0000000000001d601e05cdf83ae8 Content-Type: text/plain; charset="UTF-8" On Sat, Oct 9, 2021 at 10:06 PM Baptiste Daroussin wrote: > On Sun, Oct 10, 2021 at 02:52:58AM +0300, Konstantin Belousov wrote: > > On Sat, Oct 09, 2021 at 05:29:39PM -0600, Warner Losh wrote: > > > On Sat, Oct 9, 2021, 5:15 PM Konstantin Belousov > > > wrote: > > > > > > > On Sat, Oct 09, 2021 at 04:47:35PM -0600, Warner Losh wrote: > > > > > On Sat, Oct 9, 2021 at 11:09 AM Dimitry Andric > wrote: > > > > > > > > > > > On 9 Oct 2021, at 15:40, Warner Losh wrote: > > > > > > > > > > > > > > On Sat, Oct 9, 2021, 5:59 AM Dimitry Andric > wrote: > > > > > > > On 9 Oct 2021, at 13:37, Dimitry Andric > wrote: > > > > > > > > > > > > > > > > On 9 Oct 2021, at 09:46, FreeBSD User < > freebsd@walstatt-de.de> > > > > wrote: > > > > > > > >> > > > > > > > >> On recent CURRENT (FreeBSD 14.0-CURRENT #2 > > > > main-n249971-0525ece3554e: > > > > > > > >> Fri Oct 8 15:17:34 CEST 2021 amd64) building of an > 13-STABLE > > > > based > > > > > > > >> appliance failed very early in the build process of the > 13-STABLE > > > > > > > >> sources as shown below. 13-STABLE is most recent, since the > > > > sources > > > > > > are > > > > > > > >> fetched every time the build process is triggered. > > > > > > > > ... > > > > > > > >> > > > > > > > /pool/home/ohartmann/Projects/router/router/apu2c4/src/tools/install.sh > > > > > > > >> -s -o root -g wheel -m 555 compile_et > > > > > > > >> /pool/home/ohartmann/Projects/router/router/apu2 > > > > > > > >> > > > > > > > > > > > c4/world/amd64/ALERICH_13-STABLE_amd64/pool/home/ohartmann/Projects/router/router/apu2c4/src/amd64.amd64/tmp/legacy/usr/bin/compile_et > > > > > > > >> --- _bootstrap-tools-usr.bin/clang/llvm-tblgen --- ld: > error: > > > > > > undefined > > > > > > > >> symbol: setupterm > > > > > > > >>>>> referenced by Process.cpp > > > > > > > >>>>> > > > > > > Process.o:(llvm::sys::Process::FileDescriptorHasColors(int)) > > > > > > > > > > > > > > > > It is complaining about ncurses functions; it seems that even > > > > though > > > > > > the link step gets -lncursesw added, it still is not able to > find the > > > > > > symbol: > > > > > > > > > > > > > > Okay, this is because recently on -CURRENT, libtinfow got > split off > > > > from > > > > > > > libncursesw: > https://cgit.freebsd.org/src/commit/?id=396851c20aebd > > > > > > > > > > > > > > This affects such cross-builds obviously, and manually adding > > > > -ltinfow > > > > > > > to the link command line makes it link correctly. > > > > > > > > > > > > > > However, the 396851c20aebd commit is probably not suitable for > > > > MFC'ing > > > > > > > to stable/13. Maybe we need to put some kind of kludge in > > > > > > > share/mk/src.libnames.mk for this, or in the top-level > > > > Makefile.inc1? > > > > > > > > > > > > > > Baptiste, any ideas? :) > > > > > > > > > > > > > > Add setupterm() to libegacy as a nop. > > > > > > > > > > > > That's not enough I think, it requires more ncurses functions > than just > > > > > > setupterm. And it actually calls them and checks the return > values too, > > > > > > IIRC. :) > > > > > > > > > > > > > > > > int setupterm(const char *t, int fd, int *errptr) { return OK; } > > > > > int tigetnum(const char *t) { return 0; } > > > > > TERMINAL *set_curterm(TERMINAL *t) { return NULL; } > > > > > int del_curterm(TERMINAL *t) { return OK; } > > > > > > > > > > should do the trick. I'll see just how crazy an idea this might be > > > > > since we're trying to get the first stage tool to work on a > -current > > > > > host. the only thing that clang is really using is tigetnum to see > > > > > if the terminal has color. Returning 0 tells it no. > > > > > > > > > > Or we could contrive, during bootstrap, to ensure that > > > > > LLVM_ENABLE_TERMINFO is not defined. Nobody ever needs > > > > > color error messages. They are nice to have, sure, but are not > > > > > strictly needed if the alternative is monochrome error messages > > > > > while building the system. There's already an ifdef protecting it: > > > > > > > > > > /* Define if the setupterm() function is supported this platform. > */ > > > > > #if defined(__FreeBSD__) > > > > > /* > > > > > * This is only needed for terminalHasColors(). When disabled LLVM > falls > > > > > back > > > > > * to checking a list of TERM prefixes which is sufficient for a > > > > bootstrap > > > > > tool. > > > > > */ > > > > > #define LLVM_ENABLE_TERMINFO 1 > > > > > #endif > > > > > > > > > > It would be easy enough to add a && !defined(LLVM_BOOTSTRAP_BUILD) > > > > > or similar. > > > > > > > > I do not quite understand how would it help. > > > > You need to add this to HEAD sources back in time, not to the current > > > > sources. > > > > > > > > > > Once merged, this would get stable building on current. But not older > > > versions of stable, it is true. It's worth doing for that reason alone > > > unless there's something clever we've not thought of yet with the > current > > > host. > > > > We can put somewhere a patch and add instructions how to use it to patch > > older HEADs and stable. May be instructions and the reference to the > patch > > file should go into UPDATING 20211004 entry. > > It fails to link because the bootstrap tools are built statically if they > were > linked dynamically that would solve the situation, because libncursesw.so > is a > linkscript which does the right thing. > > Stupid question, why are bootstrap tools statically linked in the first > place? > If we remove -DNO_SHARED from the BARGS, it compiles perfectly fine. > I support this. It's a lot better than my idea. I did a deep dive with 'git blame' and after a look way back in time, this was added back when miniperl was added to the cross tools as a "while I'm here" change stop building the bootstrap shared and profile binaries (so it was an optimization). This will increase the build time a bit since we build libraries twice now (both static and shared). But we don't normally build libraries when bootstrapping, though. Back when this change was done, we built a lot during the bootstrapping. But that's no longer the case. 12 -> 13 (or current) will build a couple of libraries, so if they are built both shared and static the added time will be, at best, negligible. From older upgrades, more is built, but newer clang versions likely make it impossible to upgrade from such versions (likely time to GC them... I'll take a look at doing that). Warner P.S. Here's where it was added: commit ad879ce9552cb94f4709c6e41a31a060d1c9c335 Author: Marcel Moolenaar Date: Mon Nov 20 02:17:34 2000 +0000 Fix cross-building. o Move building libperl and miniperl from build-tools to cross-tools. libperl uses MACHINE_ARCH to determine the right configuration, which doesn't match the build machine when cross-building if they are built as build- tools. o Since miniperl needs to be built as a cross-tool, it needs to be installed under /usr/obj so that it can be used (cross-tools have a special object directory to avoid build conflicts. As a downside, you can't easily run cross-tools from their object directory). Remove the install and distribute override targets. To avoid having miniperl installed by installworld, remove it from SUBDIR. o We can't pickup miniperl from the object directory but since it's installed, depend on PATH. This is save, because the makefiles are run with a known path. o Build libperl again as part of the library target. A _libperl variable existed, but it was never defined. o Add chmod to the list of saved tools, because perl conditionally uses it during install. The bootstrap-tools and cross-tools targets are modified to avoid building profiled and shared libraries. While here, have these targets build static binaries instead of shared binaries. Approved by: markm Notes: svn path=/head/; revision=68927 > Imho we should remove the static linking here, the other way would be to > provide a "flat" libncursesw.a for those cases on CURRENT. which I don't > know how to > provide without breaking things even more. > > Best regards, > Bapt > --0000000000001d601e05cdf83ae8-- From nobody Sun Oct 10 04:45:22 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id ECD1812DC111 for ; Sun, 10 Oct 2021 04:45:23 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vs1-xe2a.google.com (mail-vs1-xe2a.google.com [IPv6:2607:f8b0:4864:20::e2a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HRq9b67lRz4ZWl for ; Sun, 10 Oct 2021 04:45:23 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vs1-xe2a.google.com with SMTP id o15so10283434vsr.13 for ; Sat, 09 Oct 2021 21:45:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kzDblGeYE2vdA/2L1JfN2U0qa4a5+DL/JzHpVpY7fAs=; b=3fn3XedyouZ5udA86K1yptpF7wiAv1k5JTj2cG2L8ZdW+/+FyHg/JFT5yO5bw0WLXA ceEhyA9byy8ejktEdyupqBdXzhYaK0AyawGVRpZ8Zm2GP6IKNwfY7obbt/zreUZDHPgE GuIiVXjBajWIVS6pCeRS9AdFu7fHfCRnKKFygNg24NuaFdgKEfWkMBvTBiHTYd1WQyXa HInA+Ytxz2qZdYibNitrA0VndF8tw5fVR/L42PcElPm4+293OIUJaV36HtbPeTptqp5y jtQ4mOCPB44QbUwJKP/QVMsKm50P8EfHIoWfgCjr27aYC7jnrxuGiWkY+nqSqNvhCMjr vhnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kzDblGeYE2vdA/2L1JfN2U0qa4a5+DL/JzHpVpY7fAs=; b=5t3oVoe3uWxHvNCiIyfeTQ9rbYxZbJe4NGpcUv1vi2Pz1BiSpykhbsc1fHXZLRak1w 2+3MKHnAMU4UsGKutPWcWH5RalPTz4uYF5MOOSdnM4ik0xCLX5s97LPrqYZoMKdz502/ klFFqd4sr439JJhtnq0KlC10zHfJGd0KVZP4DbgBthRtY67VbS4E6zMuVLnn8KciOC2O tYQ/gf3bGPrbyPwF5VsWN7ilcCAMKdSzUQ/9ECjClVVReyyZqD7oOqKHrZC1naVRHOqU aMvh/qTAYAu8tdqQHglgrbkGH48GEtoWqAFA+FqGylEqZel/2LrlRiXzjG5m63Y63ChY iT4w== X-Gm-Message-State: AOAM532paWNjkk9Dq6D9gZv316XIkCMliIgrkvGmGvDBTEvK9DGUPL8Z kaoFAmEO+ycl2d/3yBjbspZOLAlUlJELo5AUMBrFrw== X-Google-Smtp-Source: ABdhPJzM5DJXVZLd6zrOECFk+i+7/QhSsUuwIOOh8mRKjoum+7q5Kw3dgev/ryhMu1SHyO0bp3Bd/sPS29KuT5Lr99Q= X-Received: by 2002:a05:6102:6ce:: with SMTP id m14mr18393194vsg.42.1633841123362; Sat, 09 Oct 2021 21:45:23 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <20211009094624.3f3cacc8@jelly.fritz.box> <2FCA108B-29E1-48EA-A8C7-BC621CC6F963@FreeBSD.org> <94E84785-8F8C-4E90-A437-929565F5C968@FreeBSD.org> <20211010040637.3fw7q6nl7gn7aum4@aniel.nours.eu> <20211010044111.mvzuepff34ztqctq@aniel.nours.eu> In-Reply-To: <20211010044111.mvzuepff34ztqctq@aniel.nours.eu> From: Warner Losh Date: Sat, 9 Oct 2021 22:45:22 -0600 Message-ID: Subject: Re: clang/llvm-tblgen --- ld: error: undefined symbol: setupterm To: Baptiste Daroussin Cc: Konstantin Belousov , Dimitry Andric , FreeBSD User , FreeBSD CURRENT Content-Type: multipart/alternative; boundary="000000000000c71db805cdf8478a" X-Rspamd-Queue-Id: 4HRq9b67lRz4ZWl X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --000000000000c71db805cdf8478a Content-Type: text/plain; charset="UTF-8" On Sat, Oct 9, 2021 at 10:41 PM Baptiste Daroussin wrote: > On Sun, Oct 10, 2021 at 06:06:37AM +0200, Baptiste Daroussin wrote: > > On Sun, Oct 10, 2021 at 02:52:58AM +0300, Konstantin Belousov wrote: > > > On Sat, Oct 09, 2021 at 05:29:39PM -0600, Warner Losh wrote: > > > > On Sat, Oct 9, 2021, 5:15 PM Konstantin Belousov < > kostikbel@gmail.com> > > > > wrote: > > > > > > > > > On Sat, Oct 09, 2021 at 04:47:35PM -0600, Warner Losh wrote: > > > > > > On Sat, Oct 9, 2021 at 11:09 AM Dimitry Andric > wrote: > > > > > > > > > > > > > On 9 Oct 2021, at 15:40, Warner Losh wrote: > > > > > > > > > > > > > > > > On Sat, Oct 9, 2021, 5:59 AM Dimitry Andric > wrote: > > > > > > > > On 9 Oct 2021, at 13:37, Dimitry Andric > wrote: > > > > > > > > > > > > > > > > > > On 9 Oct 2021, at 09:46, FreeBSD User < > freebsd@walstatt-de.de> > > > > > wrote: > > > > > > > > >> > > > > > > > > >> On recent CURRENT (FreeBSD 14.0-CURRENT #2 > > > > > main-n249971-0525ece3554e: > > > > > > > > >> Fri Oct 8 15:17:34 CEST 2021 amd64) building of an > 13-STABLE > > > > > based > > > > > > > > >> appliance failed very early in the build process of the > 13-STABLE > > > > > > > > >> sources as shown below. 13-STABLE is most recent, since > the > > > > > sources > > > > > > > are > > > > > > > > >> fetched every time the build process is triggered. > > > > > > > > > ... > > > > > > > > >> > > > > > > > > /pool/home/ohartmann/Projects/router/router/apu2c4/src/tools/install.sh > > > > > > > > >> -s -o root -g wheel -m 555 compile_et > > > > > > > > >> /pool/home/ohartmann/Projects/router/router/apu2 > > > > > > > > >> > > > > > > > > > > > > > c4/world/amd64/ALERICH_13-STABLE_amd64/pool/home/ohartmann/Projects/router/router/apu2c4/src/amd64.amd64/tmp/legacy/usr/bin/compile_et > > > > > > > > >> --- _bootstrap-tools-usr.bin/clang/llvm-tblgen --- ld: > error: > > > > > > > undefined > > > > > > > > >> symbol: setupterm > > > > > > > > >>>>> referenced by Process.cpp > > > > > > > > >>>>> > > > > > > > Process.o:(llvm::sys::Process::FileDescriptorHasColors(int)) > > > > > > > > > > > > > > > > > > It is complaining about ncurses functions; it seems that > even > > > > > though > > > > > > > the link step gets -lncursesw added, it still is not able to > find the > > > > > > > symbol: > > > > > > > > > > > > > > > > Okay, this is because recently on -CURRENT, libtinfow got > split off > > > > > from > > > > > > > > libncursesw: > https://cgit.freebsd.org/src/commit/?id=396851c20aebd > > > > > > > > > > > > > > > > This affects such cross-builds obviously, and manually adding > > > > > -ltinfow > > > > > > > > to the link command line makes it link correctly. > > > > > > > > > > > > > > > > However, the 396851c20aebd commit is probably not suitable > for > > > > > MFC'ing > > > > > > > > to stable/13. Maybe we need to put some kind of kludge in > > > > > > > > share/mk/src.libnames.mk for this, or in the top-level > > > > > Makefile.inc1? > > > > > > > > > > > > > > > > Baptiste, any ideas? :) > > > > > > > > > > > > > > > > Add setupterm() to libegacy as a nop. > > > > > > > > > > > > > > That's not enough I think, it requires more ncurses functions > than just > > > > > > > setupterm. And it actually calls them and checks the return > values too, > > > > > > > IIRC. :) > > > > > > > > > > > > > > > > > > > int setupterm(const char *t, int fd, int *errptr) { return OK; } > > > > > > int tigetnum(const char *t) { return 0; } > > > > > > TERMINAL *set_curterm(TERMINAL *t) { return NULL; } > > > > > > int del_curterm(TERMINAL *t) { return OK; } > > > > > > > > > > > > should do the trick. I'll see just how crazy an idea this might > be > > > > > > since we're trying to get the first stage tool to work on a > -current > > > > > > host. the only thing that clang is really using is tigetnum to > see > > > > > > if the terminal has color. Returning 0 tells it no. > > > > > > > > > > > > Or we could contrive, during bootstrap, to ensure that > > > > > > LLVM_ENABLE_TERMINFO is not defined. Nobody ever needs > > > > > > color error messages. They are nice to have, sure, but are not > > > > > > strictly needed if the alternative is monochrome error messages > > > > > > while building the system. There's already an ifdef protecting > it: > > > > > > > > > > > > /* Define if the setupterm() function is supported this > platform. */ > > > > > > #if defined(__FreeBSD__) > > > > > > /* > > > > > > * This is only needed for terminalHasColors(). When disabled > LLVM falls > > > > > > back > > > > > > * to checking a list of TERM prefixes which is sufficient for a > > > > > bootstrap > > > > > > tool. > > > > > > */ > > > > > > #define LLVM_ENABLE_TERMINFO 1 > > > > > > #endif > > > > > > > > > > > > It would be easy enough to add a && > !defined(LLVM_BOOTSTRAP_BUILD) > > > > > > or similar. > > > > > > > > > > I do not quite understand how would it help. > > > > > You need to add this to HEAD sources back in time, not to the > current > > > > > sources. > > > > > > > > > > > > > Once merged, this would get stable building on current. But not older > > > > versions of stable, it is true. It's worth doing for that reason > alone > > > > unless there's something clever we've not thought of yet with the > current > > > > host. > > > > > > We can put somewhere a patch and add instructions how to use it to > patch > > > older HEADs and stable. May be instructions and the reference to the > patch > > > file should go into UPDATING 20211004 entry. > > > > It fails to link because the bootstrap tools are built statically if > they were > > linked dynamically that would solve the situation, because > libncursesw.so is a > > linkscript which does the right thing. > > > > Stupid question, why are bootstrap tools statically linked in the first > place? > > If we remove -DNO_SHARED from the BARGS, it compiles perfectly fine. > > > > Imho we should remove the static linking here, the other way would be to > > provide a "flat" libncursesw.a for those cases on CURRENT. which I don't > know how to > > provide without breaking things even more. > > > > Best regards, > > Bapt > > the reason being -DNO_SHARED is speeding up the bootstrap, so probably we > need > to either investigate make ncurses a bootstrap lib for clang, or having > kind of > an equivalent of what the linker script is doing for libncursesw.so but for > libncursesw.a. > We build so few libraries (usually none) that we can ditch this optimization for the upgrades (the libraries built are usually tiny). Warner --000000000000c71db805cdf8478a-- From nobody Sun Oct 10 05:15:54 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 39F0F17E0329 for ; Sun, 10 Oct 2021 05:16:13 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vs1-xe2c.google.com (mail-vs1-xe2c.google.com [IPv6:2607:f8b0:4864:20::e2c]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature 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 4HRqs82yw7z4dLp for ; Sun, 10 Oct 2021 05:16:12 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vs1-xe2c.google.com with SMTP id a10so4746502vsr.1 for ; Sat, 09 Oct 2021 22:16:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ICUq3WMTWIgYWlh5SseVDQ+RelRwgmLv2uEbt6p/gWA=; b=dRMLDL75ekD0Dm+zFcsiUt7yevDWYZyihJzxaxOyKvmFSipbIk2VZ96a2tBVTEK6Sh SfOi3Z0VBP5W/eMsZ8p+BIWizCqavO0ZhlmxXOQ2J20wclYQmWfF6suX2DgOZjLphojt RATADHRtXAgHc1dmgaW9ebgvheNzz9wXBM9xxOXBvyx+lCDgJCjtKmz89E8AEW2W4TAp N3NgSkHpokFtJP5qiIGqj+gM6VHEawyBwCtK8ixOogl908JdBwUOEStQd2xqm/BrPzKz frtHQsts4SHk8BEvFc0Stdj0dVS6EyV8Cm3+eDfzA/pNA2ucD7w3pzVNGgqCiHef1pnp 0hbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ICUq3WMTWIgYWlh5SseVDQ+RelRwgmLv2uEbt6p/gWA=; b=Tm7Ed6aSYdu/fvQaIY+H3hDMcTiodOELNkKfQgSvQSsGoEXv8lBysA8JJCluy5ITN3 7Dv6Nxj+yq740qSMf2q1aq/mrGrfp6eSP8LumpkvcvHPOYiWoa596Ue4/Y65T7aeq+NO PEOLaDLSwHfR6QBbRrO+owb7ujQ4DlF4ulsKn4tbetLFBjNZjqHnQoS8Pi90z5uufHL8 SWKNATEFQsVSHliBiKgj1HnTIXgg/JnuP3Pi8b6B34JUMovhxJj4L/8iC/TDE/DOptuP 5mTc7ynwRN5dwAdVIeTq+XsNEjd8H9CqRjbXduF3fPzJTbHFxyGejfWnQUBxAKKUiHwP zSGA== X-Gm-Message-State: AOAM530s0qufzXAeWDKrdkGK+E6dgV2eTG8JBhu3njxJ6A7pkbBu7YvT i6JkoOAyKcqIRo+1DiRGQSTd6P0fVw5yEfmhUqXi3Q== X-Google-Smtp-Source: ABdhPJwEzkT7Qae+gddqDEQ7YTbHHJ0/vEIMwoGEfvX0uDKNpnXq7C3aSyxTf+dwkbHmleV+KvgnEOAW1SyNwdnKxVs= X-Received: by 2002:a67:fc8b:: with SMTP id x11mr3727496vsp.12.1633842965587; Sat, 09 Oct 2021 22:16:05 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <20211009094624.3f3cacc8@jelly.fritz.box> <2FCA108B-29E1-48EA-A8C7-BC621CC6F963@FreeBSD.org> <94E84785-8F8C-4E90-A437-929565F5C968@FreeBSD.org> <20211010040637.3fw7q6nl7gn7aum4@aniel.nours.eu> <20211010044111.mvzuepff34ztqctq@aniel.nours.eu> In-Reply-To: From: Warner Losh Date: Sat, 9 Oct 2021 23:15:54 -0600 Message-ID: Subject: Re: clang/llvm-tblgen --- ld: error: undefined symbol: setupterm To: Baptiste Daroussin Cc: Konstantin Belousov , Dimitry Andric , FreeBSD User , FreeBSD CURRENT Content-Type: multipart/alternative; boundary="000000000000953f2105cdf8b536" X-Rspamd-Queue-Id: 4HRqs82yw7z4dLp X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=dRMLDL75; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::e2c) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-3.00 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; NEURAL_HAM_SHORT(-1.00)[-0.999]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::e2c:from]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_COUNT_TWO(0.00)[2]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org,walstatt-de.de] X-ThisMailContainsUnwantedMimeParts: Y --000000000000953f2105cdf8b536 Content-Type: text/plain; charset="UTF-8" On Sat, Oct 9, 2021 at 10:45 PM Warner Losh wrote: > > > On Sat, Oct 9, 2021 at 10:41 PM Baptiste Daroussin > wrote: > >> On Sun, Oct 10, 2021 at 06:06:37AM +0200, Baptiste Daroussin wrote: >> > On Sun, Oct 10, 2021 at 02:52:58AM +0300, Konstantin Belousov wrote: >> > > On Sat, Oct 09, 2021 at 05:29:39PM -0600, Warner Losh wrote: >> > > > On Sat, Oct 9, 2021, 5:15 PM Konstantin Belousov < >> kostikbel@gmail.com> >> > > > wrote: >> > > > >> > > > > On Sat, Oct 09, 2021 at 04:47:35PM -0600, Warner Losh wrote: >> > > > > > On Sat, Oct 9, 2021 at 11:09 AM Dimitry Andric >> wrote: >> > > > > > >> > > > > > > On 9 Oct 2021, at 15:40, Warner Losh wrote: >> > > > > > > > >> > > > > > > > On Sat, Oct 9, 2021, 5:59 AM Dimitry Andric < >> dim@freebsd.org> wrote: >> > > > > > > > On 9 Oct 2021, at 13:37, Dimitry Andric >> wrote: >> > > > > > > > > >> > > > > > > > > On 9 Oct 2021, at 09:46, FreeBSD User < >> freebsd@walstatt-de.de> >> > > > > wrote: >> > > > > > > > >> >> > > > > > > > >> On recent CURRENT (FreeBSD 14.0-CURRENT #2 >> > > > > main-n249971-0525ece3554e: >> > > > > > > > >> Fri Oct 8 15:17:34 CEST 2021 amd64) building of an >> 13-STABLE >> > > > > based >> > > > > > > > >> appliance failed very early in the build process of the >> 13-STABLE >> > > > > > > > >> sources as shown below. 13-STABLE is most recent, since >> the >> > > > > sources >> > > > > > > are >> > > > > > > > >> fetched every time the build process is triggered. >> > > > > > > > > ... >> > > > > > > > >> >> > > > > > > >> /pool/home/ohartmann/Projects/router/router/apu2c4/src/tools/install.sh >> > > > > > > > >> -s -o root -g wheel -m 555 compile_et >> > > > > > > > >> /pool/home/ohartmann/Projects/router/router/apu2 >> > > > > > > > >> >> > > > > > > >> > > > > >> c4/world/amd64/ALERICH_13-STABLE_amd64/pool/home/ohartmann/Projects/router/router/apu2c4/src/amd64.amd64/tmp/legacy/usr/bin/compile_et >> > > > > > > > >> --- _bootstrap-tools-usr.bin/clang/llvm-tblgen --- ld: >> error: >> > > > > > > undefined >> > > > > > > > >> symbol: setupterm >> > > > > > > > >>>>> referenced by Process.cpp >> > > > > > > > >>>>> >> > > > > > > Process.o:(llvm::sys::Process::FileDescriptorHasColors(int)) >> > > > > > > > > >> > > > > > > > > It is complaining about ncurses functions; it seems that >> even >> > > > > though >> > > > > > > the link step gets -lncursesw added, it still is not able to >> find the >> > > > > > > symbol: >> > > > > > > > >> > > > > > > > Okay, this is because recently on -CURRENT, libtinfow got >> split off >> > > > > from >> > > > > > > > libncursesw: >> https://cgit.freebsd.org/src/commit/?id=396851c20aebd >> > > > > > > > >> > > > > > > > This affects such cross-builds obviously, and manually >> adding >> > > > > -ltinfow >> > > > > > > > to the link command line makes it link correctly. >> > > > > > > > >> > > > > > > > However, the 396851c20aebd commit is probably not suitable >> for >> > > > > MFC'ing >> > > > > > > > to stable/13. Maybe we need to put some kind of kludge in >> > > > > > > > share/mk/src.libnames.mk for this, or in the top-level >> > > > > Makefile.inc1? >> > > > > > > > >> > > > > > > > Baptiste, any ideas? :) >> > > > > > > > >> > > > > > > > Add setupterm() to libegacy as a nop. >> > > > > > > >> > > > > > > That's not enough I think, it requires more ncurses functions >> than just >> > > > > > > setupterm. And it actually calls them and checks the return >> values too, >> > > > > > > IIRC. :) >> > > > > > > >> > > > > > >> > > > > > int setupterm(const char *t, int fd, int *errptr) { return OK; } >> > > > > > int tigetnum(const char *t) { return 0; } >> > > > > > TERMINAL *set_curterm(TERMINAL *t) { return NULL; } >> > > > > > int del_curterm(TERMINAL *t) { return OK; } >> > > > > > >> > > > > > should do the trick. I'll see just how crazy an idea this might >> be >> > > > > > since we're trying to get the first stage tool to work on a >> -current >> > > > > > host. the only thing that clang is really using is tigetnum to >> see >> > > > > > if the terminal has color. Returning 0 tells it no. >> > > > > > >> > > > > > Or we could contrive, during bootstrap, to ensure that >> > > > > > LLVM_ENABLE_TERMINFO is not defined. Nobody ever needs >> > > > > > color error messages. They are nice to have, sure, but are not >> > > > > > strictly needed if the alternative is monochrome error messages >> > > > > > while building the system. There's already an ifdef protecting >> it: >> > > > > > >> > > > > > /* Define if the setupterm() function is supported this >> platform. */ >> > > > > > #if defined(__FreeBSD__) >> > > > > > /* >> > > > > > * This is only needed for terminalHasColors(). When disabled >> LLVM falls >> > > > > > back >> > > > > > * to checking a list of TERM prefixes which is sufficient for a >> > > > > bootstrap >> > > > > > tool. >> > > > > > */ >> > > > > > #define LLVM_ENABLE_TERMINFO 1 >> > > > > > #endif >> > > > > > >> > > > > > It would be easy enough to add a && >> !defined(LLVM_BOOTSTRAP_BUILD) >> > > > > > or similar. >> > > > > >> > > > > I do not quite understand how would it help. >> > > > > You need to add this to HEAD sources back in time, not to the >> current >> > > > > sources. >> > > > > >> > > > >> > > > Once merged, this would get stable building on current. But not >> older >> > > > versions of stable, it is true. It's worth doing for that reason >> alone >> > > > unless there's something clever we've not thought of yet with the >> current >> > > > host. >> > > >> > > We can put somewhere a patch and add instructions how to use it to >> patch >> > > older HEADs and stable. May be instructions and the reference to the >> patch >> > > file should go into UPDATING 20211004 entry. >> > >> > It fails to link because the bootstrap tools are built statically if >> they were >> > linked dynamically that would solve the situation, because >> libncursesw.so is a >> > linkscript which does the right thing. >> > >> > Stupid question, why are bootstrap tools statically linked in the first >> place? >> > If we remove -DNO_SHARED from the BARGS, it compiles perfectly fine. >> > >> > Imho we should remove the static linking here, the other way would be to >> > provide a "flat" libncursesw.a for those cases on CURRENT. which I >> don't know how to >> > provide without breaking things even more. >> > >> > Best regards, >> > Bapt >> >> the reason being -DNO_SHARED is speeding up the bootstrap, so probably we >> need >> to either investigate make ncurses a bootstrap lib for clang, or having >> kind of >> an equivalent of what the linker script is doing for libncursesw.so but >> for >> libncursesw.a. >> > > We build so few libraries (usually none) that we can ditch this > optimization for > the upgrades (the libraries built are usually tiny). > Though it's still a 'patch the past' path forward... The fix is trivial to describe. Warner --000000000000953f2105cdf8b536-- From nobody Sun Oct 10 05:29:01 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 5E3A917E270E for ; Sun, 10 Oct 2021 05:29:14 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HRr8B22fyz4gZZ; Sun, 10 Oct 2021 05:29:14 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-qk1-f169.google.com (mail-qk1-f169.google.com [209.85.222.169]) (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: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 1EFC327CCF; Sun, 10 Oct 2021 05:29:14 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-qk1-f169.google.com with SMTP id x12so13609813qkf.9; Sat, 09 Oct 2021 22:29:14 -0700 (PDT) X-Gm-Message-State: AOAM531XzhEcUwkJ1YWlUoePHB1KWv+85tOKuwWoCqdGoYKx6j6xqU1U xr7CzueQR2/bgajgtLmPX/xmyxaP5Tt1fle2MM8= X-Google-Smtp-Source: ABdhPJy3zET/my9TRNJFaStvgs0Jt0HHIBeH+GZ6zPkBOpNLjUUvMDgWlgjZe1qK6USz4Vy0gmkHTwI+rpqnJwaYw+c= X-Received: by 2002:a37:9f02:: with SMTP id i2mr10004864qke.305.1633843753487; Sat, 09 Oct 2021 22:29:13 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <20211009094624.3f3cacc8@jelly.fritz.box> <2FCA108B-29E1-48EA-A8C7-BC621CC6F963@FreeBSD.org> <94E84785-8F8C-4E90-A437-929565F5C968@FreeBSD.org> <20211010040637.3fw7q6nl7gn7aum4@aniel.nours.eu> <20211010044111.mvzuepff34ztqctq@aniel.nours.eu> In-Reply-To: From: Kyle Evans Date: Sun, 10 Oct 2021 00:29:01 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: clang/llvm-tblgen --- ld: error: undefined symbol: setupterm To: Warner Losh Cc: Baptiste Daroussin , Konstantin Belousov , Dimitry Andric , FreeBSD User , FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" X-ThisMailContainsUnwantedMimeParts: N On Sun, Oct 10, 2021 at 12:18 AM Warner Losh wrote: > > On Sat, Oct 9, 2021 at 10:45 PM Warner Losh wrote: > > > > > > > On Sat, Oct 9, 2021 at 10:41 PM Baptiste Daroussin > > wrote: > > > >> On Sun, Oct 10, 2021 at 06:06:37AM +0200, Baptiste Daroussin wrote: > >> > On Sun, Oct 10, 2021 at 02:52:58AM +0300, Konstantin Belousov wrote: > >> > > On Sat, Oct 09, 2021 at 05:29:39PM -0600, Warner Losh wrote: > >> > > > On Sat, Oct 9, 2021, 5:15 PM Konstantin Belousov < > >> kostikbel@gmail.com> > >> > > > wrote: > >> > > > > >> > > > > On Sat, Oct 09, 2021 at 04:47:35PM -0600, Warner Losh wrote: > >> > > > > > On Sat, Oct 9, 2021 at 11:09 AM Dimitry Andric > >> wrote: > >> > > > > > > >> > > > > > > On 9 Oct 2021, at 15:40, Warner Losh wrote: > >> > > > > > > > > >> > > > > > > > On Sat, Oct 9, 2021, 5:59 AM Dimitry Andric < > >> dim@freebsd.org> wrote: > >> > > > > > > > On 9 Oct 2021, at 13:37, Dimitry Andric > >> wrote: > >> > > > > > > > > > >> > > > > > > > > On 9 Oct 2021, at 09:46, FreeBSD User < > >> freebsd@walstatt-de.de> > >> > > > > wrote: > >> > > > > > > > >> > >> > > > > > > > >> On recent CURRENT (FreeBSD 14.0-CURRENT #2 > >> > > > > main-n249971-0525ece3554e: > >> > > > > > > > >> Fri Oct 8 15:17:34 CEST 2021 amd64) building of an > >> 13-STABLE > >> > > > > based > >> > > > > > > > >> appliance failed very early in the build process of the > >> 13-STABLE > >> > > > > > > > >> sources as shown below. 13-STABLE is most recent, since > >> the > >> > > > > sources > >> > > > > > > are > >> > > > > > > > >> fetched every time the build process is triggered. > >> > > > > > > > > ... > >> > > > > > > > >> > >> > > > > > > > >> /pool/home/ohartmann/Projects/router/router/apu2c4/src/tools/install.sh > >> > > > > > > > >> -s -o root -g wheel -m 555 compile_et > >> > > > > > > > >> /pool/home/ohartmann/Projects/router/router/apu2 > >> > > > > > > > >> > >> > > > > > > > >> > > > > > >> c4/world/amd64/ALERICH_13-STABLE_amd64/pool/home/ohartmann/Projects/router/router/apu2c4/src/amd64.amd64/tmp/legacy/usr/bin/compile_et > >> > > > > > > > >> --- _bootstrap-tools-usr.bin/clang/llvm-tblgen --- ld: > >> error: > >> > > > > > > undefined > >> > > > > > > > >> symbol: setupterm > >> > > > > > > > >>>>> referenced by Process.cpp > >> > > > > > > > >>>>> > >> > > > > > > Process.o:(llvm::sys::Process::FileDescriptorHasColors(int)) > >> > > > > > > > > > >> > > > > > > > > It is complaining about ncurses functions; it seems that > >> even > >> > > > > though > >> > > > > > > the link step gets -lncursesw added, it still is not able to > >> find the > >> > > > > > > symbol: > >> > > > > > > > > >> > > > > > > > Okay, this is because recently on -CURRENT, libtinfow got > >> split off > >> > > > > from > >> > > > > > > > libncursesw: > >> https://cgit.freebsd.org/src/commit/?id=396851c20aebd > >> > > > > > > > > >> > > > > > > > This affects such cross-builds obviously, and manually > >> adding > >> > > > > -ltinfow > >> > > > > > > > to the link command line makes it link correctly. > >> > > > > > > > > >> > > > > > > > However, the 396851c20aebd commit is probably not suitable > >> for > >> > > > > MFC'ing > >> > > > > > > > to stable/13. Maybe we need to put some kind of kludge in > >> > > > > > > > share/mk/src.libnames.mk for this, or in the top-level > >> > > > > Makefile.inc1? > >> > > > > > > > > >> > > > > > > > Baptiste, any ideas? :) > >> > > > > > > > > >> > > > > > > > Add setupterm() to libegacy as a nop. > >> > > > > > > > >> > > > > > > That's not enough I think, it requires more ncurses functions > >> than just > >> > > > > > > setupterm. And it actually calls them and checks the return > >> values too, > >> > > > > > > IIRC. :) > >> > > > > > > > >> > > > > > > >> > > > > > int setupterm(const char *t, int fd, int *errptr) { return OK; } > >> > > > > > int tigetnum(const char *t) { return 0; } > >> > > > > > TERMINAL *set_curterm(TERMINAL *t) { return NULL; } > >> > > > > > int del_curterm(TERMINAL *t) { return OK; } > >> > > > > > > >> > > > > > should do the trick. I'll see just how crazy an idea this might > >> be > >> > > > > > since we're trying to get the first stage tool to work on a > >> -current > >> > > > > > host. the only thing that clang is really using is tigetnum to > >> see > >> > > > > > if the terminal has color. Returning 0 tells it no. > >> > > > > > > >> > > > > > Or we could contrive, during bootstrap, to ensure that > >> > > > > > LLVM_ENABLE_TERMINFO is not defined. Nobody ever needs > >> > > > > > color error messages. They are nice to have, sure, but are not > >> > > > > > strictly needed if the alternative is monochrome error messages > >> > > > > > while building the system. There's already an ifdef protecting > >> it: > >> > > > > > > >> > > > > > /* Define if the setupterm() function is supported this > >> platform. */ > >> > > > > > #if defined(__FreeBSD__) > >> > > > > > /* > >> > > > > > * This is only needed for terminalHasColors(). When disabled > >> LLVM falls > >> > > > > > back > >> > > > > > * to checking a list of TERM prefixes which is sufficient for a > >> > > > > bootstrap > >> > > > > > tool. > >> > > > > > */ > >> > > > > > #define LLVM_ENABLE_TERMINFO 1 > >> > > > > > #endif > >> > > > > > > >> > > > > > It would be easy enough to add a && > >> !defined(LLVM_BOOTSTRAP_BUILD) > >> > > > > > or similar. > >> > > > > > >> > > > > I do not quite understand how would it help. > >> > > > > You need to add this to HEAD sources back in time, not to the > >> current > >> > > > > sources. > >> > > > > > >> > > > > >> > > > Once merged, this would get stable building on current. But not > >> older > >> > > > versions of stable, it is true. It's worth doing for that reason > >> alone > >> > > > unless there's something clever we've not thought of yet with the > >> current > >> > > > host. > >> > > > >> > > We can put somewhere a patch and add instructions how to use it to > >> patch > >> > > older HEADs and stable. May be instructions and the reference to the > >> patch > >> > > file should go into UPDATING 20211004 entry. > >> > > >> > It fails to link because the bootstrap tools are built statically if > >> they were > >> > linked dynamically that would solve the situation, because > >> libncursesw.so is a > >> > linkscript which does the right thing. > >> > > >> > Stupid question, why are bootstrap tools statically linked in the first > >> place? > >> > If we remove -DNO_SHARED from the BARGS, it compiles perfectly fine. > >> > > >> > Imho we should remove the static linking here, the other way would be to > >> > provide a "flat" libncursesw.a for those cases on CURRENT. which I > >> don't know how to > >> > provide without breaking things even more. > >> > > >> > Best regards, > >> > Bapt > >> > >> the reason being -DNO_SHARED is speeding up the bootstrap, so probably we > >> need > >> to either investigate make ncurses a bootstrap lib for clang, or having > >> kind of > >> an equivalent of what the linker script is doing for libncursesw.so but > >> for > >> libncursesw.a. > >> > > > > We build so few libraries (usually none) that we can ditch this > > optimization for > > the upgrades (the libraries built are usually tiny). > > > > Though it's still a 'patch the past' path forward... The fix is trivial to > describe. > It doesn't sound like there's any need to 'patch the past'... the status quo is that the static libncursesw is effectively "broken" because consumers need to know to link to libtinfow. If the linker script idea works (which it seems like it will) then it's a non-issue; either we're building on a system that has the all-in-one libncursesw or we're building against a linker script that also does the right thing. From nobody Sun Oct 10 05:33:54 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 6F88017E3A9E for ; Sun, 10 Oct 2021 05:34:06 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ua1-x92b.google.com (mail-ua1-x92b.google.com [IPv6:2607:f8b0:4864:20::92b]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HRrFp2Db0z4hpW for ; Sun, 10 Oct 2021 05:34:06 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ua1-x92b.google.com with SMTP id i15so5590633uap.0 for ; Sat, 09 Oct 2021 22:34:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WoORAwYg1b8ZM7ENbp9FdV9WwhHMmQalPUBPN8fArV8=; b=d72ypZ1VO1KThaBsSJwbzKfKNMo+q7fzu+YxBiCANM/R4lvaFE7qk54FbfzYGmdelR W2lrZ1P4QyQNgUMQ095VOA2Agp3viWclqq5q1kcWa+nkxi+YMAmGM6raNk8F9LToT8b/ y4BmoUtItmhI/cx2bbZdrKbh/Brn+SE/j2LSlyvjt+eh2+GbX9sX5I4LTLu4dfIp9OQ1 1gdTl5eMiTtfDLX59aMLxI9gomWRMhhAZip5prpXY8RX1tNXST3GOc7GVtDEPf/t4Ubp 965D1biXQOPRC4lJZa8LtQfFMXp22iflTQqxVVSGN5vxzVjnnhs24eUjDYeAg2CmRQaZ SGKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WoORAwYg1b8ZM7ENbp9FdV9WwhHMmQalPUBPN8fArV8=; b=ha3WZz+TdxOpjV+Et7O9wZBk9zrbdDZINBkKq1QD8KlTLkMQvCZRBxVY0xwhcsrQ3c /m2cB68qdVqpHeGNPxwz1bhjQsh5Zs3h2XabmP6Mi3MV+DWKKGUiivAV1zQ9xirOy697 /aa00IXG6Nh65Wr6+yDeG9CiamVmeMeJlHAO9dEzM3ZA8GL2HnnNiXEET9+/HkdtIUaL JwLufVb4PCr3L8HRO5loNQqaGZyl7ZNmf3SS2nLFSINxQlrilqy/Py/B8EB+ZYhSKUjV BEI+6XZDbm97xzKOK99pS6+4WuXKJPnMFaEDD+jtZoEY6Ab3baL5Q5XDt2T+lPCdb/UG PmMA== X-Gm-Message-State: AOAM5317N4y1VFo9hQsF+TtEEJ2r9DYiW1FPZ9mWiJCrEz6Z9zkH/ywm FSvCfxLhpPtXP/W4PVcP4RNYKRp5SRNQgDdYLJlo5A== X-Google-Smtp-Source: ABdhPJyzee/pAA7NiWVwJ7e4FXGpTJuDDP24gA0B8+aLIXcSaXDGWcOyPS7G3aiex8Z0CEi/ACSRKk1SRceW2Xw1F1g= X-Received: by 2002:a9f:23d0:: with SMTP id 74mr10472331uao.69.1633844045824; Sat, 09 Oct 2021 22:34:05 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <20211009094624.3f3cacc8@jelly.fritz.box> <2FCA108B-29E1-48EA-A8C7-BC621CC6F963@FreeBSD.org> <94E84785-8F8C-4E90-A437-929565F5C968@FreeBSD.org> <20211010040637.3fw7q6nl7gn7aum4@aniel.nours.eu> <20211010044111.mvzuepff34ztqctq@aniel.nours.eu> In-Reply-To: From: Warner Losh Date: Sat, 9 Oct 2021 23:33:54 -0600 Message-ID: Subject: Re: clang/llvm-tblgen --- ld: error: undefined symbol: setupterm To: Kyle Evans Cc: Baptiste Daroussin , Konstantin Belousov , Dimitry Andric , FreeBSD User , FreeBSD CURRENT Content-Type: multipart/alternative; boundary="000000000000f85c2505cdf8f53b" X-Rspamd-Queue-Id: 4HRrFp2Db0z4hpW X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --000000000000f85c2505cdf8f53b Content-Type: text/plain; charset="UTF-8" On Sat, Oct 9, 2021 at 11:29 PM Kyle Evans wrote: > On Sun, Oct 10, 2021 at 12:18 AM Warner Losh wrote: > > > > On Sat, Oct 9, 2021 at 10:45 PM Warner Losh wrote: > > > > > > > > > > > On Sat, Oct 9, 2021 at 10:41 PM Baptiste Daroussin > > > wrote: > > > > > >> On Sun, Oct 10, 2021 at 06:06:37AM +0200, Baptiste Daroussin wrote: > > >> > On Sun, Oct 10, 2021 at 02:52:58AM +0300, Konstantin Belousov wrote: > > >> > > On Sat, Oct 09, 2021 at 05:29:39PM -0600, Warner Losh wrote: > > >> > > > On Sat, Oct 9, 2021, 5:15 PM Konstantin Belousov < > > >> kostikbel@gmail.com> > > >> > > > wrote: > > >> > > > > > >> > > > > On Sat, Oct 09, 2021 at 04:47:35PM -0600, Warner Losh wrote: > > >> > > > > > On Sat, Oct 9, 2021 at 11:09 AM Dimitry Andric < > dim@freebsd.org> > > >> wrote: > > >> > > > > > > > >> > > > > > > On 9 Oct 2021, at 15:40, Warner Losh > wrote: > > >> > > > > > > > > > >> > > > > > > > On Sat, Oct 9, 2021, 5:59 AM Dimitry Andric < > > >> dim@freebsd.org> wrote: > > >> > > > > > > > On 9 Oct 2021, at 13:37, Dimitry Andric > > > >> wrote: > > >> > > > > > > > > > > >> > > > > > > > > On 9 Oct 2021, at 09:46, FreeBSD User < > > >> freebsd@walstatt-de.de> > > >> > > > > wrote: > > >> > > > > > > > >> > > >> > > > > > > > >> On recent CURRENT (FreeBSD 14.0-CURRENT #2 > > >> > > > > main-n249971-0525ece3554e: > > >> > > > > > > > >> Fri Oct 8 15:17:34 CEST 2021 amd64) building of an > > >> 13-STABLE > > >> > > > > based > > >> > > > > > > > >> appliance failed very early in the build process of > the > > >> 13-STABLE > > >> > > > > > > > >> sources as shown below. 13-STABLE is most recent, > since > > >> the > > >> > > > > sources > > >> > > > > > > are > > >> > > > > > > > >> fetched every time the build process is triggered. > > >> > > > > > > > > ... > > >> > > > > > > > >> > > >> > > > > > > > > >> > /pool/home/ohartmann/Projects/router/router/apu2c4/src/tools/install.sh > > >> > > > > > > > >> -s -o root -g wheel -m 555 compile_et > > >> > > > > > > > >> /pool/home/ohartmann/Projects/router/router/apu2 > > >> > > > > > > > >> > > >> > > > > > > > > >> > > > > > > >> > c4/world/amd64/ALERICH_13-STABLE_amd64/pool/home/ohartmann/Projects/router/router/apu2c4/src/amd64.amd64/tmp/legacy/usr/bin/compile_et > > >> > > > > > > > >> --- _bootstrap-tools-usr.bin/clang/llvm-tblgen --- > ld: > > >> error: > > >> > > > > > > undefined > > >> > > > > > > > >> symbol: setupterm > > >> > > > > > > > >>>>> referenced by Process.cpp > > >> > > > > > > > >>>>> > > >> > > > > > > > Process.o:(llvm::sys::Process::FileDescriptorHasColors(int)) > > >> > > > > > > > > > > >> > > > > > > > > It is complaining about ncurses functions; it seems > that > > >> even > > >> > > > > though > > >> > > > > > > the link step gets -lncursesw added, it still is not able > to > > >> find the > > >> > > > > > > symbol: > > >> > > > > > > > > > >> > > > > > > > Okay, this is because recently on -CURRENT, libtinfow > got > > >> split off > > >> > > > > from > > >> > > > > > > > libncursesw: > > >> https://cgit.freebsd.org/src/commit/?id=396851c20aebd > > >> > > > > > > > > > >> > > > > > > > This affects such cross-builds obviously, and manually > > >> adding > > >> > > > > -ltinfow > > >> > > > > > > > to the link command line makes it link correctly. > > >> > > > > > > > > > >> > > > > > > > However, the 396851c20aebd commit is probably not > suitable > > >> for > > >> > > > > MFC'ing > > >> > > > > > > > to stable/13. Maybe we need to put some kind of kludge > in > > >> > > > > > > > share/mk/src.libnames.mk for this, or in the top-level > > >> > > > > Makefile.inc1? > > >> > > > > > > > > > >> > > > > > > > Baptiste, any ideas? :) > > >> > > > > > > > > > >> > > > > > > > Add setupterm() to libegacy as a nop. > > >> > > > > > > > > >> > > > > > > That's not enough I think, it requires more ncurses > functions > > >> than just > > >> > > > > > > setupterm. And it actually calls them and checks the > return > > >> values too, > > >> > > > > > > IIRC. :) > > >> > > > > > > > > >> > > > > > > > >> > > > > > int setupterm(const char *t, int fd, int *errptr) { return > OK; } > > >> > > > > > int tigetnum(const char *t) { return 0; } > > >> > > > > > TERMINAL *set_curterm(TERMINAL *t) { return NULL; } > > >> > > > > > int del_curterm(TERMINAL *t) { return OK; } > > >> > > > > > > > >> > > > > > should do the trick. I'll see just how crazy an idea this > might > > >> be > > >> > > > > > since we're trying to get the first stage tool to work on a > > >> -current > > >> > > > > > host. the only thing that clang is really using is tigetnum > to > > >> see > > >> > > > > > if the terminal has color. Returning 0 tells it no. > > >> > > > > > > > >> > > > > > Or we could contrive, during bootstrap, to ensure that > > >> > > > > > LLVM_ENABLE_TERMINFO is not defined. Nobody ever needs > > >> > > > > > color error messages. They are nice to have, sure, but are > not > > >> > > > > > strictly needed if the alternative is monochrome error > messages > > >> > > > > > while building the system. There's already an ifdef > protecting > > >> it: > > >> > > > > > > > >> > > > > > /* Define if the setupterm() function is supported this > > >> platform. */ > > >> > > > > > #if defined(__FreeBSD__) > > >> > > > > > /* > > >> > > > > > * This is only needed for terminalHasColors(). When > disabled > > >> LLVM falls > > >> > > > > > back > > >> > > > > > * to checking a list of TERM prefixes which is sufficient > for a > > >> > > > > bootstrap > > >> > > > > > tool. > > >> > > > > > */ > > >> > > > > > #define LLVM_ENABLE_TERMINFO 1 > > >> > > > > > #endif > > >> > > > > > > > >> > > > > > It would be easy enough to add a && > > >> !defined(LLVM_BOOTSTRAP_BUILD) > > >> > > > > > or similar. > > >> > > > > > > >> > > > > I do not quite understand how would it help. > > >> > > > > You need to add this to HEAD sources back in time, not to the > > >> current > > >> > > > > sources. > > >> > > > > > > >> > > > > > >> > > > Once merged, this would get stable building on current. But not > > >> older > > >> > > > versions of stable, it is true. It's worth doing for that reason > > >> alone > > >> > > > unless there's something clever we've not thought of yet with > the > > >> current > > >> > > > host. > > >> > > > > >> > > We can put somewhere a patch and add instructions how to use it to > > >> patch > > >> > > older HEADs and stable. May be instructions and the reference to > the > > >> patch > > >> > > file should go into UPDATING 20211004 entry. > > >> > > > >> > It fails to link because the bootstrap tools are built statically if > > >> they were > > >> > linked dynamically that would solve the situation, because > > >> libncursesw.so is a > > >> > linkscript which does the right thing. > > >> > > > >> > Stupid question, why are bootstrap tools statically linked in the > first > > >> place? > > >> > If we remove -DNO_SHARED from the BARGS, it compiles perfectly fine. > > >> > > > >> > Imho we should remove the static linking here, the other way would > be to > > >> > provide a "flat" libncursesw.a for those cases on CURRENT. which I > > >> don't know how to > > >> > provide without breaking things even more. > > >> > > > >> > Best regards, > > >> > Bapt > > >> > > >> the reason being -DNO_SHARED is speeding up the bootstrap, so > probably we > > >> need > > >> to either investigate make ncurses a bootstrap lib for clang, or > having > > >> kind of > > >> an equivalent of what the linker script is doing for libncursesw.so > but > > >> for > > >> libncursesw.a. > > >> > > > > > > We build so few libraries (usually none) that we can ditch this > > > optimization for > > > the upgrades (the libraries built are usually tiny). > > > > > > > Though it's still a 'patch the past' path forward... The fix is trivial > to > > describe. > > > > It doesn't sound like there's any need to 'patch the past'... the > status quo is that the static libncursesw is effectively "broken" > because consumers need to know to link to libtinfow. If the linker > script idea works (which it seems like it will) then it's a non-issue; > either we're building on a system that has the all-in-one libncursesw > or we're building against a linker script that also does the right > thing. > Yea, the linker script notion is the only thing that's talked about so far that's something where we don't need to patch the past. The old tools know how to cope with the linker script and will bring the right things in. My comments were about removing -DNO_SHARED... We should remove -DNO_SHARED as well from the bootstrap tools, but that's a separate issue if the linker script works. Warner --000000000000f85c2505cdf8f53b-- From nobody Sun Oct 10 05:45:19 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id ED96917E50BE for ; Sun, 10 Oct 2021 05:45:21 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HRrVn6MBjz4kBG; Sun, 10 Oct 2021 05:45:21 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: from aniel.nours.eu (nours.eu [IPv6:2001:41d0:8:3a4d::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: bapt) by smtp.freebsd.org (Postfix) with ESMTPSA id 8DB1E282D4; Sun, 10 Oct 2021 05:45:21 +0000 (UTC) (envelope-from bapt@freebsd.org) Received: by aniel.nours.eu (Postfix, from userid 1001) id C923060DA1; Sun, 10 Oct 2021 07:45:19 +0200 (CEST) Date: Sun, 10 Oct 2021 07:45:19 +0200 From: Baptiste Daroussin To: Warner Losh Cc: Kyle Evans , Konstantin Belousov , Dimitry Andric , FreeBSD User , FreeBSD CURRENT Subject: Re: clang/llvm-tblgen --- ld: error: undefined symbol: setupterm Message-ID: <20211010054519.ennyyt3qba3reaop@aniel.nours.eu> References: <20211010040637.3fw7q6nl7gn7aum4@aniel.nours.eu> <20211010044111.mvzuepff34ztqctq@aniel.nours.eu> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-ThisMailContainsUnwantedMimeParts: N On Sat, Oct 09, 2021 at 11:33:54PM -0600, Warner Losh wrote: > On Sat, Oct 9, 2021 at 11:29 PM Kyle Evans wrote: > > > On Sun, Oct 10, 2021 at 12:18 AM Warner Losh wrote: > > > > > > On Sat, Oct 9, 2021 at 10:45 PM Warner Losh wrote: > > > > > > > > > > > > > > > On Sat, Oct 9, 2021 at 10:41 PM Baptiste Daroussin > > > > wrote: > > > > > > > >> On Sun, Oct 10, 2021 at 06:06:37AM +0200, Baptiste Daroussin wrote: > > > >> > On Sun, Oct 10, 2021 at 02:52:58AM +0300, Konstantin Belousov wrote: > > > >> > > On Sat, Oct 09, 2021 at 05:29:39PM -0600, Warner Losh wrote: > > > >> > > > On Sat, Oct 9, 2021, 5:15 PM Konstantin Belousov < > > > >> kostikbel@gmail.com> > > > >> > > > wrote: > > > >> > > > > > > >> > > > > On Sat, Oct 09, 2021 at 04:47:35PM -0600, Warner Losh wrote: > > > >> > > > > > On Sat, Oct 9, 2021 at 11:09 AM Dimitry Andric < > > dim@freebsd.org> > > > >> wrote: > > > >> > > > > > > > > >> > > > > > > On 9 Oct 2021, at 15:40, Warner Losh > > wrote: > > > >> > > > > > > > > > > >> > > > > > > > On Sat, Oct 9, 2021, 5:59 AM Dimitry Andric < > > > >> dim@freebsd.org> wrote: > > > >> > > > > > > > On 9 Oct 2021, at 13:37, Dimitry Andric > > > > > >> wrote: > > > >> > > > > > > > > > > > >> > > > > > > > > On 9 Oct 2021, at 09:46, FreeBSD User < > > > >> freebsd@walstatt-de.de> > > > >> > > > > wrote: > > > >> > > > > > > > >> > > > >> > > > > > > > >> On recent CURRENT (FreeBSD 14.0-CURRENT #2 > > > >> > > > > main-n249971-0525ece3554e: > > > >> > > > > > > > >> Fri Oct 8 15:17:34 CEST 2021 amd64) building of an > > > >> 13-STABLE > > > >> > > > > based > > > >> > > > > > > > >> appliance failed very early in the build process of > > the > > > >> 13-STABLE > > > >> > > > > > > > >> sources as shown below. 13-STABLE is most recent, > > since > > > >> the > > > >> > > > > sources > > > >> > > > > > > are > > > >> > > > > > > > >> fetched every time the build process is triggered. > > > >> > > > > > > > > ... > > > >> > > > > > > > >> > > > >> > > > > > > > > > >> > > /pool/home/ohartmann/Projects/router/router/apu2c4/src/tools/install.sh > > > >> > > > > > > > >> -s -o root -g wheel -m 555 compile_et > > > >> > > > > > > > >> /pool/home/ohartmann/Projects/router/router/apu2 > > > >> > > > > > > > >> > > > >> > > > > > > > > > >> > > > > > > > >> > > c4/world/amd64/ALERICH_13-STABLE_amd64/pool/home/ohartmann/Projects/router/router/apu2c4/src/amd64.amd64/tmp/legacy/usr/bin/compile_et > > > >> > > > > > > > >> --- _bootstrap-tools-usr.bin/clang/llvm-tblgen --- > > ld: > > > >> error: > > > >> > > > > > > undefined > > > >> > > > > > > > >> symbol: setupterm > > > >> > > > > > > > >>>>> referenced by Process.cpp > > > >> > > > > > > > >>>>> > > > >> > > > > > > > > Process.o:(llvm::sys::Process::FileDescriptorHasColors(int)) > > > >> > > > > > > > > > > > >> > > > > > > > > It is complaining about ncurses functions; it seems > > that > > > >> even > > > >> > > > > though > > > >> > > > > > > the link step gets -lncursesw added, it still is not able > > to > > > >> find the > > > >> > > > > > > symbol: > > > >> > > > > > > > > > > >> > > > > > > > Okay, this is because recently on -CURRENT, libtinfow > > got > > > >> split off > > > >> > > > > from > > > >> > > > > > > > libncursesw: > > > >> https://cgit.freebsd.org/src/commit/?id=396851c20aebd > > > >> > > > > > > > > > > >> > > > > > > > This affects such cross-builds obviously, and manually > > > >> adding > > > >> > > > > -ltinfow > > > >> > > > > > > > to the link command line makes it link correctly. > > > >> > > > > > > > > > > >> > > > > > > > However, the 396851c20aebd commit is probably not > > suitable > > > >> for > > > >> > > > > MFC'ing > > > >> > > > > > > > to stable/13. Maybe we need to put some kind of kludge > > in > > > >> > > > > > > > share/mk/src.libnames.mk for this, or in the top-level > > > >> > > > > Makefile.inc1? > > > >> > > > > > > > > > > >> > > > > > > > Baptiste, any ideas? :) > > > >> > > > > > > > > > > >> > > > > > > > Add setupterm() to libegacy as a nop. > > > >> > > > > > > > > > >> > > > > > > That's not enough I think, it requires more ncurses > > functions > > > >> than just > > > >> > > > > > > setupterm. And it actually calls them and checks the > > return > > > >> values too, > > > >> > > > > > > IIRC. :) > > > >> > > > > > > > > > >> > > > > > > > > >> > > > > > int setupterm(const char *t, int fd, int *errptr) { return > > OK; } > > > >> > > > > > int tigetnum(const char *t) { return 0; } > > > >> > > > > > TERMINAL *set_curterm(TERMINAL *t) { return NULL; } > > > >> > > > > > int del_curterm(TERMINAL *t) { return OK; } > > > >> > > > > > > > > >> > > > > > should do the trick. I'll see just how crazy an idea this > > might > > > >> be > > > >> > > > > > since we're trying to get the first stage tool to work on a > > > >> -current > > > >> > > > > > host. the only thing that clang is really using is tigetnum > > to > > > >> see > > > >> > > > > > if the terminal has color. Returning 0 tells it no. > > > >> > > > > > > > > >> > > > > > Or we could contrive, during bootstrap, to ensure that > > > >> > > > > > LLVM_ENABLE_TERMINFO is not defined. Nobody ever needs > > > >> > > > > > color error messages. They are nice to have, sure, but are > > not > > > >> > > > > > strictly needed if the alternative is monochrome error > > messages > > > >> > > > > > while building the system. There's already an ifdef > > protecting > > > >> it: > > > >> > > > > > > > > >> > > > > > /* Define if the setupterm() function is supported this > > > >> platform. */ > > > >> > > > > > #if defined(__FreeBSD__) > > > >> > > > > > /* > > > >> > > > > > * This is only needed for terminalHasColors(). When > > disabled > > > >> LLVM falls > > > >> > > > > > back > > > >> > > > > > * to checking a list of TERM prefixes which is sufficient > > for a > > > >> > > > > bootstrap > > > >> > > > > > tool. > > > >> > > > > > */ > > > >> > > > > > #define LLVM_ENABLE_TERMINFO 1 > > > >> > > > > > #endif > > > >> > > > > > > > > >> > > > > > It would be easy enough to add a && > > > >> !defined(LLVM_BOOTSTRAP_BUILD) > > > >> > > > > > or similar. > > > >> > > > > > > > >> > > > > I do not quite understand how would it help. > > > >> > > > > You need to add this to HEAD sources back in time, not to the > > > >> current > > > >> > > > > sources. > > > >> > > > > > > > >> > > > > > > >> > > > Once merged, this would get stable building on current. But not > > > >> older > > > >> > > > versions of stable, it is true. It's worth doing for that reason > > > >> alone > > > >> > > > unless there's something clever we've not thought of yet with > > the > > > >> current > > > >> > > > host. > > > >> > > > > > >> > > We can put somewhere a patch and add instructions how to use it to > > > >> patch > > > >> > > older HEADs and stable. May be instructions and the reference to > > the > > > >> patch > > > >> > > file should go into UPDATING 20211004 entry. > > > >> > > > > >> > It fails to link because the bootstrap tools are built statically if > > > >> they were > > > >> > linked dynamically that would solve the situation, because > > > >> libncursesw.so is a > > > >> > linkscript which does the right thing. > > > >> > > > > >> > Stupid question, why are bootstrap tools statically linked in the > > first > > > >> place? > > > >> > If we remove -DNO_SHARED from the BARGS, it compiles perfectly fine. > > > >> > > > > >> > Imho we should remove the static linking here, the other way would > > be to > > > >> > provide a "flat" libncursesw.a for those cases on CURRENT. which I > > > >> don't know how to > > > >> > provide without breaking things even more. > > > >> > > > > >> > Best regards, > > > >> > Bapt > > > >> > > > >> the reason being -DNO_SHARED is speeding up the bootstrap, so > > probably we > > > >> need > > > >> to either investigate make ncurses a bootstrap lib for clang, or > > having > > > >> kind of > > > >> an equivalent of what the linker script is doing for libncursesw.so > > but > > > >> for > > > >> libncursesw.a. > > > >> > > > > > > > > We build so few libraries (usually none) that we can ditch this > > > > optimization for > > > > the upgrades (the libraries built are usually tiny). > > > > > > > > > > Though it's still a 'patch the past' path forward... The fix is trivial > > to > > > describe. > > > > > > > It doesn't sound like there's any need to 'patch the past'... the > > status quo is that the static libncursesw is effectively "broken" > > because consumers need to know to link to libtinfow. If the linker > > script idea works (which it seems like it will) then it's a non-issue; > > either we're building on a system that has the all-in-one libncursesw > > or we're building against a linker script that also does the right > > thing. > > > > Yea, the linker script notion is the only thing that's talked about so > far that's something where we don't need to patch the past. The > old tools know how to cope with the linker script and will bring the > right things in. My comments were about removing -DNO_SHARED... > > We should remove -DNO_SHARED as well from the bootstrap tools, > but that's a separate issue if the linker script works. > > Warner This https://reviews.freebsd.org/D32435 should make freebsd stable 12 and 13 buildable out of box again on freebsd 14. Best regards, Bapt From nobody Sun Oct 10 05:48:58 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0C72217E6207 for ; Sun, 10 Oct 2021 05:49:12 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-eopbgr670040.outbound.protection.outlook.com [40.107.67.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HRrbC68q4z4lBB; Sun, 10 Oct 2021 05:49:11 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EO8Nuc/xWHRpj4KdqkduGgeIcT3JbC5AsVz3Ws1agV91iJmkoXD0t4YDmavUkUYxPLaOmbXGO93yOQ20qTPWqV/DMbjl0LwMLTjIBHhqnl4rvHSO/y4Te8LEXWvhgXAAZk3NXFggR/qwLsoouuyYDIUIHQS9VHGc7cySI+V9zIQEhBrXroPGRqsQIeKhh3w6u89RbCWF94tzNIMcxP1QxHucRV2YMIqWrIuZApl1IMko2u69YhXbrExrqMbTHoy9sBTiDJRrcHUdfSDLIBFlslh7zUv/rWuiGxlzs6z3uPghxHLGSRbpuy1ZFxrEnOvjG0bKBoyXh6pEXOoNE42dWg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=KCgMDNCqx7aUHaUbZGAGENipF7/nNMYqFFZPH97tYRI=; b=YWsCkz2lQjqYasYv+gXhJZXlK+oSDyko6UVg8QHw3t+LdjaG55M2S2qhppOgTcc6/+aFroG7T3Yu+n38QBgMK25ZlRqo8jXGWwanNMbbNVO43+bF7n0/24lAfSuPVDbr0QVWV5QkGnpwOLpW84EpSu3SE0cNwmbQNjg7/93iocgEaDhEXvNtxHThQdno5zpdpXdFMDf3+PnvzL/28c1pB4WXNM4EmPG0E1iaKH+qruSyeBH9oJHtFY7ZsJbNKXETMnmEw0B1rD4h6ym05efTry2JDxVoXkAsmduWI3mOC5zpEsXLK+DiQVDUp9zV9X+wwYZs6zqadc/MF3RIR69hMg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KCgMDNCqx7aUHaUbZGAGENipF7/nNMYqFFZPH97tYRI=; b=jRYKNkDmvDePvGcL9YpuozmflMMJQ3uww3b3XVqgzBB8OnbJePCUzV+Rc5OijGOzQRFrVcOkkD87MZjASlV19uiAuuvUmK/aD/x4qkQSVHb6x6jNbz9QQS9vxspisQxbzKKJvOCXE5jqOHJPltK9jONWwdjVT/s8u15OIS/hnHrVZxuiYh//yiOQVhG9aeaEzrFauJq3uJSol8njeqe6LrAtq6+7NB2akpj7LBTpQDmphntxSH/NEpuPuSdQje/h/z1zx2BfjovzZ8OQUmbE6K7mamt0qM0mX3M3XvsiBWkChoWrmGsvQlaMFUHCoyNuFvDWURoETxKgYWabmUk1rA== Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:19::29) by YQBPR0101MB2082.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:f::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.20; Sun, 10 Oct 2021 05:49:04 +0000 Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::7091:13ac:171f:1c12]) by YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::7091:13ac:171f:1c12%5]) with mapi id 15.20.4587.025; Sun, 10 Oct 2021 05:48:58 +0000 From: Rick Macklem To: Alan Somers CC: FreeBSD Current Subject: Re: RFC: Use of VOP_ALLOCATE() by NFSV4.2 nfsd Thread-Topic: RFC: Use of VOP_ALLOCATE() by NFSV4.2 nfsd Thread-Index: AQHXvXMbM0Hsf8N9W0qQA3mOobhhb6vLmYKAgAAgm70= Date: Sun, 10 Oct 2021 05:48:58 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: 44c6e91b-d802-7831-4db3-d209c52cedcc x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a45acddc-1864-46c6-373c-08d98bb1a765 x-ms-traffictypediagnostic: YQBPR0101MB2082: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: KNt2I2zLdPgh03Zlr+FLseQS/26kNag/JHi0dFa12Y/dyXkhdI8TeJmH39qJSk9huWpMisqxh3WhRoV1VppKJnZ0LN52TaWLWmOOWYSkBvc5EN+jrdZubEyixv/REuy1W059E/YYrdljRfHcQej09eHbfSxnWMWaF3ooU24DXiWIwmA2FvHasTZNMpT7OrqAD2Jk8kcSTRySS+6Zs92js/EoxTJuolaNfsPU3rgLMGRiLEIKXXwJaId30l/IQf5/cyeZWyOWCY6UXJ89+5pLXSwjD7LoaptUUfBhepf2TB/OjhluduGpMtpUTRvzmnoX1qbEg+BQCDncorN546pNVf092AHnGB6Y5Ka/Olf9qsPmODrn3tStAyYuGmx4HhBFk7A7MitHoK7X2pI+rNUq8/CABczOQZHcp95xnA30r/tBN4es5ZVYPocjUulBPHOeghUF8Id85XvyLN1tOFu9iiaf9G7SKSkAlbHxZquxz89oSNEjh9Vpth/DfkpQs1ZjWjs2FUSZIDTBia/7INhzFnhCcbcXme+IQ6RcfcEzfxDJd9YJLed+2hlpxZSW+Q8AZBsnxcMZOGJq+wQnyg43pyTfctlhbAdCOcMcHq6Eo5uIKTwlRo1MiZXtYol99KxrwjwXUWkxSrMtpR2Qb1SVh2FO0btRCaOveQpPZ5fj0iH8F17OumElExcXA45VPaD3qJyw1xmL5H13gr4W99PfaLPS+kOlRQW5haWml7YlDqY= 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)(6506007)(52536014)(450100002)(66446008)(64756008)(33656002)(2906002)(9686003)(91956017)(71200400001)(66946007)(7696005)(8676002)(53546011)(66556008)(66476007)(86362001)(76116006)(38070700005)(55016002)(6916009)(508600001)(5660300002)(38100700002)(83380400001)(786003)(8936002)(186003)(316002)(4326008)(122000001)(586874002);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?e2p1n3PeWPZFYk3G6Wm1RpeSgqtexnODBhgIG7hwTwr5Jgqesefts6Mzbn1m?= =?us-ascii?Q?W2o/avMH4UXUSxaPZBAArNerpUAgacNTqar2KwGNL3xKJ9Vi6pq7SVIJIUlc?= =?us-ascii?Q?9m4uptBIyXBck+RXugJOgvN/ALzrDb37PDa33DXlbAgKEhHMtBEoOa8IFuU5?= =?us-ascii?Q?+Mp83p4j9LxGsQEkW3Q4H2mo3Lr5BAPvgVSiB6273QgcY8hlzExeUH06DjJc?= =?us-ascii?Q?VHZv86mJJ4xlERMkruulkI/oRk2fDWKbaZP7Q9yl5UxE1WoPKzLhKWHEGovg?= =?us-ascii?Q?ZrirWjd6Bz/1weSkuFo8L44IM1oM0pIHlYuXcSHC/bDuBYM031EUPeHZniF7?= =?us-ascii?Q?Gcje1bkYKJ/0EQXCdGQVPS08ivmfg8XYEql10YbSzf7zkRdKl/sV2tyZOrK/?= =?us-ascii?Q?Ow6MddNkvKHkRXaRnW2ExO2DaHjYB0LNGAXBmffzfVJQ3r9i6Vu2DRzvHOdl?= =?us-ascii?Q?rSdIOXEIeaPMHYU6CkN3KmjlEmoHSR2j69XJVp9KR4AqmSZfsNKDgD/dLKbQ?= =?us-ascii?Q?nfOVRZ6E1sr+Fd40mnhRoCsUO2+hMnC/VRwN0iUXS43aquXQ0IPkSPZpCbsC?= =?us-ascii?Q?rSMJS8dnCkAIqQcYa0w6h2+Q+ch/IQN5N6DcZUvMlMg5xLBGolDG5JLTqVjP?= =?us-ascii?Q?y9QrVsvtLurT4G4/ERkx7ikLubqaN1aCbcE3Tc4zHdpQ8+qcJsMXMKf7dZgI?= =?us-ascii?Q?84q8cvx0uvNC3549y8lXT0fqDcKBBjENXrJTviZmiOvBhLYupggvfbNCjeD6?= =?us-ascii?Q?18qHoGKPnAB4QG3OioZUFOz4SLhu1w+2mAL2CBvNTVb4GG5O28kOQBdc3851?= =?us-ascii?Q?UmkWAK0LPt83hcKUEwq0IBtAKK2mB1MZAn/SQN6WOj+0X4vGIR66/9RATe9h?= =?us-ascii?Q?knEUFEnN1doYvNJ1/EA1ti96rUjd9gxElk8zm3+virulC96aDfRHUbWPw0Wu?= =?us-ascii?Q?sy4vIPwPo5TP993FKs+T4ZFxElAvScMn3nMIaGAe6zeyJ5QZrbyg1gSvobY2?= =?us-ascii?Q?+8qADSLLUlneLY7Z+78e5VVjqvCgc5H7FQLsBA1xRuU8uFts0mBtE3SH5u6Q?= =?us-ascii?Q?AbKCqgmF18oXYDJK8CNuhFL318Tk/db2Fe8z7C3osP50n+dNXewC7j/5L1E7?= =?us-ascii?Q?QqQAzKTCd+M4daoFo5LIuZ3WbnumdqDsBPEPBRby6TzzNpBPxTr3sxaGg5qJ?= =?us-ascii?Q?4UxX/XUg76kvNSFMIHNTk7PWvraedXcfaCGouEeef/trPNLOGq2XxAzP9CW3?= =?us-ascii?Q?j/4V7nJQ3WDXac/bcpnYRTeYVPRP/0RbsgNHarv/wd2C9H/b0Lc40uhOuO0A?= =?us-ascii?Q?RiWkF9CQxMTweq40unAvaZEPdx9AFqaEaP3sXkm+vkMxF47EysZC0FlKFOG/?= =?us-ascii?Q?Wfme6kw=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: a45acddc-1864-46c6-373c-08d98bb1a765 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Oct 2021 05:48:58.2616 (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: xn8a8fWEm7guDz/wKxFQ9SJR1nkQvCvtpAr6xVpjde6MVCljcauQHACBCfnhsALzQSfHt8SEn5D97vpzoAQ8NA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQBPR0101MB2082 X-Rspamd-Queue-Id: 4HRrbC68q4z4lBB X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N ________________________________________ From: Alan Somers Sent: Saturday, October 9, 2021 11:52 PM To: Rick Macklem Cc: FreeBSD Current Subject: Re: RFC: Use of VOP_ALLOCATE() by NFSV4.2 nfsd 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 Sat, Oct 9, 2021 at 7:13 PM Rick Macklem wrote: > > Hi, > > I ran into an issue this week during the nfsv4@ietf.org's testing event. > UFS - supports VOP_ALLOCATE() by using vop_stdallocate(). > ZFS - just return EINVAL for VOP_ALLOCATE(). > > An NFSv4.2 server can either support Allocate or not, but it has to be > for all exported file systems. That seems like a protocol bug to me. Could this be fixed in a future NFS revision? > > This leads me to a couple of questions: > - Is there a good reason for not using vop_stdallocate() for ZFS? Yes. posix_fallocate is supposed to guarantee that subsequent writes to the file will not fail with ENOSPC. But ZFS, being a copy-on-write file system, cannot possibly guarantee that. See SVN r325320. > - Should I try and support both file system types via vop_stdallocate() > or not support Allocate at all? Since you can't possibly support it for ZFS (not to mention other file systems like fusefs) you'll have to not support it at all. > > Btw, as a bit of an aside, "cc" uses posix_fallocate() and in weird ways, > such as offset=3D0, len=3D1. Why, I have no idea? > > Thanks in advance for any comments, rick > From nobody Sun Oct 10 05:57:32 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 32F3217E84BF for ; Sun, 10 Oct 2021 05:57:40 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660075.outbound.protection.outlook.com [40.107.66.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HRrn00Bf3z4nGM; Sun, 10 Oct 2021 05:57:40 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CUoRNgzXATdZ67NEe8xNMBVSKNuqHGF2t/us+VrjWLpQIThuqQBhwiS3Pv/+9fXDoxltT1urtTFjDzBevHRTc9mGJPxCn+bDx/Mybs9F++2IJVUTyBCrxk+vgg2Ys13UbTlWKf66aH/b2sfuwsXo5T0rwy/sxr5CuSFAobsvAMcGAwfMapgtTkYsRnZfLh2ej7oy26zBVCKLQ69H7YNyBXeBsegjae/pQZz8nCF8WLfJRJ66jxIh8tAYq3jPxMN+QrvCMlCcHlAhgCrVZK6wmfJ0rGPT6mekUP4fgMuMbRYjG9Y7mARVuCEHRigF7Bz9f9+pitLQspMdmQO+x8GCRA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ATVtcc/GGBWiUeKrItKQc7NdPcoLzwrGEpIxGklBhKc=; b=m4S/K3t/LE/R+9p+T6z60lunxVzK4tOfr+k2zc+7ZThbVn7ixqubkoYLqxeYNZdBMACnr60bPUI4Dz0NsSjKzYmuH45zZYkkHtzYprboU9vDYMOrU/Kb9nJEobt75QWIGYbg05OvbQk34Q6v/wnF+YXFP29gwd8rzcuN2oOz+Rozm2zOvZsOE4dbqONy8g0EOB4WO1Zh9XyV9fhAxSNNz8xWzU9OPv9kGfkUscq6E2SKoSH2cBb8HswHKjYPzNOddJhrFs0dPmLtnEH25cifIEIZ8M2CgcIW9A0i5NDVQ8N8xkvxRw3rUZjEo4RsHT+Fm+AZk/KJtnFzkBpMmmYPnw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ATVtcc/GGBWiUeKrItKQc7NdPcoLzwrGEpIxGklBhKc=; b=p8eJKVsOJmQJ5eNgPNZFbOKcb2l25B1jj4YkvRP9WKqpfoDn+u8fZ4uTuHQC6dhflUAG/qXao4ZDQyWqPUY/vlIJz6QJ5ZymRGEtpU2LcBkIzAK2MMyKz44/SVQ62XgPWHjfCeS78zfxkuR7czR/vqQg5m/K4iFLXTjJ8WD5/S44qeD7Th13cUtYDQfBdM1+6BRWlbHr0nzOy8msOwwjahD3JD85lR09RY/HPTpGxadX+rTcLOsF7evD+O57/1mGgrvBkjYg9HpYwGdAHIiIUKYvpowuX+pZQ52qOtu/WTYlUCpfeKcCzYEKirWlkfSOVnqacRwWlktE4/b7Du7jyw== Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:19::29) by YQXPR0101MB1623.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:1f::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.19; Sun, 10 Oct 2021 05:57:32 +0000 Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::7091:13ac:171f:1c12]) by YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::7091:13ac:171f:1c12%5]) with mapi id 15.20.4587.025; Sun, 10 Oct 2021 05:57:32 +0000 From: Rick Macklem To: Alan Somers CC: FreeBSD Current Subject: Re: RFC: Use of VOP_ALLOCATE() by NFSV4.2 nfsd Thread-Topic: RFC: Use of VOP_ALLOCATE() by NFSV4.2 nfsd Thread-Index: AQHXvXMbM0Hsf8N9W0qQA3mOobhhb6vLmYKAgAAg6Cc= Date: Sun, 10 Oct 2021 05:57:32 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: 50de8601-491e-aa72-1ead-c62be075b830 x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: dc38fdfd-a6a2-469e-3d8a-08d98bb2d9cc x-ms-traffictypediagnostic: YQXPR0101MB1623: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: yAAzb6DFV1lEbU9q6LvuNh1PKgPp5TBd6aRwdY/njgFgRE1Vdzfr0Msa6IrhRr1g8qZljFeu5lmj19qff30a3ITT0Fqn+X6bAoTPK0vZ9qZPlNn7+R8ARzKx+a5IDdHyDCvB25JTKvbtvhe9busjYYZktuxy/pcKJsxni7BNWnVsCU5C6pGEvLIgymwwGKgC7NzvjG9E948ciRY4JW/lH6Ck/HCjn5PJY2hNuuexM2wrgYx820kgCqeXl3aI0YlYzv9gCrFbTOMqufunG7OyjbxskleGYU0fa4ItTjlSW8cMDRtt5MJgJIG/WbeyEfqD/Ly+0ig1M6VQJFvVVqQ+P8pLG51k2rC/kMgpzlkg/EQubchwBdCGeEHBiOg9p8cb6tMWYOKIwE1cVjVU6//PTQC4n2snZrga1NPx2BtU+kg4rAne9G3pUaZmmpuL8WKx2WqdxzhtbCjJVxUR5mF/f4+xBjxCjXdH+ah9zE7ecCQwX3Tu+WesI3hL7ZgDaUd9wXrJRWX7aoxxmyEkc3MTTpCU0sRpGv07P4Wim0TE8uJaEpL8VyXIxHnOQ2YdHSfAeUyFTvwye5ZAzmbSpg2us6O2QNx3bkL7Ry+YnxtEJo/QiMjSrcWt5KBq2i3GIwUN7UPfmNZ4hc6yVHOVGyGxRfcyjwBZVY706aN9sRM/9iBvEEEHkLCz0cPZ4xEw3lEIAV6p0XLLQxIH2pKBW8x32g== 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)(7696005)(52536014)(450100002)(4326008)(186003)(6506007)(66446008)(8936002)(33656002)(86362001)(55016002)(9686003)(122000001)(71200400001)(38070700005)(64756008)(91956017)(76116006)(8676002)(38100700002)(508600001)(5660300002)(2906002)(6916009)(66946007)(316002)(786003)(66556008)(66476007);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?JP4DPR98lHXkyhrleVAZaWasQxDFFlWFj7TiDwaJm4P2RF4rChNxoG13UH?= =?iso-8859-1?Q?6lN9l0R4gcVA2WfvFL+RQvVzMFrtub/Tzp7i0zoMNrTPdxiJPIxDXI3cuR?= =?iso-8859-1?Q?9idAPRRtpCdHR1KpvYl9YQvyz2Na29ap6jUC/lmgcx0WA0/ohDhEOLFs6I?= =?iso-8859-1?Q?SOApfAhAhUtvgjwmeLAtNf1LkDjpKgLWHYDd/K1EiInBOSea+QELF7Lr8o?= =?iso-8859-1?Q?uGcDor8kSG+leeR1pxcWSz1YUtPPFYKZPOnRfVobo8bVlvft10LagFie+T?= =?iso-8859-1?Q?DfSzE9wJCm4kcrZv9W0gAsKUWHRLPzrQUDZwqAAWUWHWjzN0Sl9KGpYZD/?= =?iso-8859-1?Q?bLDpAaVmTJ89KqumtsJjSMoijVg2akDeK2Nka7njoYNEWe/73hq8zhqKxM?= =?iso-8859-1?Q?Roxw7NKyUdy7t9zjMSroHffqprGMUKzUgUxwuhahRwgxCW+Ok8pRRtodub?= =?iso-8859-1?Q?8nwGtSFCGXzYxY7os1eyROrFAgOy9XDVTt+OD014pfkLizGeZN+IHXrCWB?= =?iso-8859-1?Q?l6sRLpGjqxfbnzcy0lk0GERm3cIvULrmlkFjuOy/cG5SDnPbxX5YRPmmtn?= =?iso-8859-1?Q?t5riGTLVqvcWwyZPhRZbF0RyDRIhZdYka8xuX3b8ZqWug23r7lKXnUYlqs?= =?iso-8859-1?Q?ygRVZNl2gGybQXOpQpxcesJba3GrqNe7pRyxv5ZSobPdtBnLLzxfFQoDIm?= =?iso-8859-1?Q?n9gMu6eKJ5LSMAaWolCEqSfjVPvG3ECJoMYjD3csqYvDG0kSD8U9s3cwdi?= =?iso-8859-1?Q?Z4aGs2KK9C4k+dIXYprlVEU0CN2C0k3WLHu71Rpy/IL5zd9pB1GG4MiwaX?= =?iso-8859-1?Q?g9rkk4MfU0inCHgPbVeWlPAVY57HqGcWVuvNFfGS2WwTA5SKveXyyeX4ZI?= =?iso-8859-1?Q?zdw9/Y6k3bVUMQXy8Nqp5TJpjlejMXfjrrsHWFEetYdYPIXCsI/iS3EPj8?= =?iso-8859-1?Q?ipDDv+d+f5mvDVYhGwkkxbwNQPIzHXwYSSWapQi5MaVv1O2oeM4/f1xGz+?= =?iso-8859-1?Q?VdFWXSfwioMpZ9pTXb+XTdlXhB9+EEhkCr5RVsjRFhT/o8baQMfqqo8LT8?= =?iso-8859-1?Q?nzxEPBRmwssF8RrkvwReAbFircM0yQUUGLB49wpRd+j6NNITSIXxYiPIA9?= =?iso-8859-1?Q?BkFPkqZ7L/hqtj8HiV7pAS2eeur+QeL1HHzTCQOJaH5281ah1lUNedoECc?= =?iso-8859-1?Q?Q49vYyFkk9eE+KXkhIu8m0eHxtoCv6XgvbPDrohtTwGGYC69RcCNlZwxAx?= =?iso-8859-1?Q?n1GcWDKpj4fSwB5a0DOySEpTC7SDCYl0vPIOwZK7g4zRImMx9dNVHGviQD?= =?iso-8859-1?Q?kjrcuS8AhU73aTHORxhGAdg61qHpdYH6l75bipTapQj8zlIcUJ9KY+g8EW?= =?iso-8859-1?Q?pjCuIOMOQDAQ6bTzTb1iKOz5UKy5R/IvzmXBnwmkBAHDnuzTgYLZ1kifg/?= =?iso-8859-1?Q?lDxS2ssm2lGf54Lk?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: dc38fdfd-a6a2-469e-3d8a-08d98bb2d9cc X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Oct 2021 05:57:32.3496 (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: NgHmQSj2U5HrmguaM5XH3lSVbs9OhEcQr9a3aF/uiKm/DpXG1FMw256zlbYHSIdwVUMi7LfTTniGosREgh5OxQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQXPR0101MB1623 X-Rspamd-Queue-Id: 4HRrn00Bf3z4nGM X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Alan Somers wrote:=0A= >On Sat, Oct 9, 2021 at 7:13 PM Rick Macklem wrote:= =0A= >>=0A= >> Hi,=0A= >>=0A= >> I ran into an issue this week during the nfsv4@ietf.org's testing event.= =0A= >> UFS - supports VOP_ALLOCATE() by using vop_stdallocate().=0A= >> ZFS - just return EINVAL for VOP_ALLOCATE().=0A= >>=0A= >> An NFSv4.2 server can either support Allocate or not, but it has to be= =0A= >> for all exported file systems.=0A= >=0A= >That seems like a protocol bug to me. Could this be fixed in a future=0A= >NFS revision?=0A= Who knows. I don't see any interest in a 4.3. 4.2 is extensible, but I thin= k=0A= this is now "cast in stone".=0A= =0A= >>=0A= >> This leads me to a couple of questions:=0A= >> - Is there a good reason for not using vop_stdallocate() for ZFS?=0A= >=0A= >Yes. posix_fallocate is supposed to guarantee that subsequent writes=0A= >to the file will not fail with ENOSPC. But ZFS, being a copy-on-write=0A= >file system, cannot possibly guarantee that. See SVN r325320.=0A= However, vop_stdallocate() just does VOP_WRITE()s to the area (with=0A= bytes of data all zeros). Wouldn't that satisfy the criteria?=0A= =0A= >> - Should I try and support both file system types via vop_stdallocate()= =0A= >> or not support Allocate at all?=0A= >=0A= >Since you can't possibly support it for ZFS (not to mention other file=0A= >systems like fusefs) you'll have to not support it at all.=0A= It does sound like not supporting it is the best alternative.=0A= =0A= rick=0A= =0A= >=0A= > Btw, as a bit of an aside, "cc" uses posix_fallocate() and in weird ways,= =0A= > such as offset=3D0, len=3D1. Why, I have no idea?=0A= >=0A= > Thanks in advance for any comments, rick=0A= >=0A= From nobody Sun Oct 10 06:02:46 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 6169617EA10B for ; Sun, 10 Oct 2021 06:02:59 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vs1-xe33.google.com (mail-vs1-xe33.google.com [IPv6:2607:f8b0:4864:20::e33]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HRrv702PDz4pVl for ; Sun, 10 Oct 2021 06:02:58 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vs1-xe33.google.com with SMTP id w13so15268455vsa.2 for ; Sat, 09 Oct 2021 23:02:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HVDKb/Bn4P661p8ejWFwHTRLWdcokUBPPJA/CY3zkRM=; b=pJ/0QwZ7cJsLDf81OU3Z7J81UFxol4x/PXJEUKkrvdHN1+B5Jmxbbp1gx4OSnZDY1m wMwdbwko1YZFYe8EtoN8SzvhDqIHkg7vWIfgZhmmrFl6I/UWmz/NmFLp0/+DOWAt4yvc rrKygTUs9Q6A1/GDyZxx3KNywe/j4ZOE9nES+9KfoMEyAtNrv/uqatsTN8qarDTqrijc RyCss36n/AHBOLzUDPMKCGr/T2FmNoMhc05Pnn6slKsQ8tgsRWJUCEy7O+xTgSpMYB1d 8yxTKAtNH+/o4mjXFXU8GC0pBu+hVzCRcqYzgtv+qoFF/wYk9ZGMlly1g0Qevza6jlKk GpDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HVDKb/Bn4P661p8ejWFwHTRLWdcokUBPPJA/CY3zkRM=; b=FkfxxbhroD231hxO0JygTEe/zo+pI+6meZUeb6yqe50Ezb1daZk5eLutfCSV5lGVKr m6TfDPuP8RSmjmLaauSqvVYIWKKHkSu2imuprANFr8aw/TG7A1SwDIfufdu8R+Td897B O5nJ3bmtBT5MfFS8nUT/oWV3rJIudHXk0ikGwmuRXSi4hsvyOlu93RBD0IWPdZ0BF1/k A3ms1G8nmG0BkJtfajYdoGGzlxCZvqwIwnvU2+lWuffZb+lFcZgMww8ld2K1+ma5RShz ISS9zZj/AVrf8+AWa5OWutDuIQPIqOVWecyuqWNTDgKxaq4Yp+8JPyparqICPOOmBGa+ gYvQ== X-Gm-Message-State: AOAM533iv0h04IWWWMmKFXRUfwOs3X5dk+DyvWGNdWtXaV293pGY5cgL Cxy9NdkdSKgl7e/FCtJklzB4GEMqc2Q1uYDBc1LSDA== X-Google-Smtp-Source: ABdhPJxh4gxlD5IiEvzjuAN5Re30kS1vY14ag4ry7A+xsJB1n1tlDFANgC0gZ/xJY+IN0az10AxN4lbEk5Qv3MY3rfU= X-Received: by 2002:a05:6102:6ce:: with SMTP id m14mr18457891vsg.42.1633845778108; Sat, 09 Oct 2021 23:02:58 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Sun, 10 Oct 2021 00:02:46 -0600 Message-ID: Subject: Re: RFC: Use of VOP_ALLOCATE() by NFSV4.2 nfsd To: Rick Macklem Cc: Alan Somers , FreeBSD Current Content-Type: multipart/alternative; boundary="00000000000038ee5f05cdf95db5" X-Rspamd-Queue-Id: 4HRrv702PDz4pVl X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --00000000000038ee5f05cdf95db5 Content-Type: text/plain; charset="UTF-8" On Sat, Oct 9, 2021, 11:58 PM Rick Macklem wrote: > Alan Somers wrote: > >On Sat, Oct 9, 2021 at 7:13 PM Rick Macklem wrote: > >> > >> Hi, > >> > >> I ran into an issue this week during the nfsv4@ietf.org's testing > event. > >> UFS - supports VOP_ALLOCATE() by using vop_stdallocate(). > >> ZFS - just return EINVAL for VOP_ALLOCATE(). > >> > >> An NFSv4.2 server can either support Allocate or not, but it has to be > >> for all exported file systems. > > > >That seems like a protocol bug to me. Could this be fixed in a future > >NFS revision? > Who knows. I don't see any interest in a 4.3. 4.2 is extensible, but I > think > this is now "cast in stone". > > >> > >> This leads me to a couple of questions: > >> - Is there a good reason for not using vop_stdallocate() for ZFS? > > > >Yes. posix_fallocate is supposed to guarantee that subsequent writes > >to the file will not fail with ENOSPC. But ZFS, being a copy-on-write > >file system, cannot possibly guarantee that. See SVN r325320. > However, vop_stdallocate() just does VOP_WRITE()s to the area (with > bytes of data all zeros). Wouldn't that satisfy the criteria? > Since it is log based, that would make it worse. The blocks aren't instantly reclaimed when marked invalid. So you'd need storage for both and the 0d blocks could cause a resource shortage when the real writes come in. ZFS doesn't have a reservation system to reserve blocks in the log for a given file... Warner >> - Should I try and support both file system types via vop_stdallocate() > >> or not support Allocate at all? > > > >Since you can't possibly support it for ZFS (not to mention other file > >systems like fusefs) you'll have to not support it at all. > It does sound like not supporting it is the best alternative. > > rick > > > > > Btw, as a bit of an aside, "cc" uses posix_fallocate() and in weird ways, > > such as offset=0, len=1. Why, I have no idea? > > > > Thanks in advance for any comments, rick > > > > --00000000000038ee5f05cdf95db5-- From nobody Sun Oct 10 13:48:49 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 0A05C12DF1F7 for ; Sun, 10 Oct 2021 13:49:08 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ot1-f41.google.com (mail-ot1-f41.google.com [209.85.210.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 4HS3Dz6ngKz4nSl for ; Sun, 10 Oct 2021 13:49:07 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-ot1-f41.google.com with SMTP id s18-20020a0568301e1200b0054e77a16651so1366714otr.7 for ; Sun, 10 Oct 2021 06:49:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tFpF2tvVTMTB3g76ffSEqMCIAEgv7cyezZo70PSFqRE=; b=lsyZin3ZYcyEtJezvSJ1Zfg0HF3w6LXscJGd9qRdLfhjEkQKYdKFXl5M4rlgPyzLt9 eGwbt/CgAu6VNtyVkBv6YM0x1EWj+IiKzyarg0le0rf7EhOVo2uhj9+xQ6KTrpLPSXKS ms9nKEbT2zCP0w97KqgWjyAvWNhZZGKcZmSQ6gKZSjBdlDnY9xYhRN51qT+bGZaA7Sio n645qHrffcvynvKrVTWKPZxjM0iXC0iHJtVDOE3diLlDCHhKFTEuBxLdy0+8XTbBw1rV SG8lqKJ26dTEgZ+0JrWlB45u0uBZusayuIV58bDuRVLxSMb0VDQ7SU0JxihL9MTExury m+4g== X-Gm-Message-State: AOAM53366Nvfls+VXH3JG9O3Ks9HsJ9dKf8PtjVAjZVEsSIHZoL9tC+p IuSZdDzzFgrl0iiTahsQ5/05/feWK8rU6KRy6MwC2c2V X-Google-Smtp-Source: ABdhPJz5Yuqe/Lr/9TOgbZ0d44plY8cbRP0kDRtApPxpI4DxibuYcx0lYiJJ95gQZkI9GdBj6q9LFQ4whN9GuPqiiMk= X-Received: by 2002:a05:6830:44ab:: with SMTP id r43mr16980040otv.371.1633873740908; Sun, 10 Oct 2021 06:49:00 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Alan Somers Date: Sun, 10 Oct 2021 07:48:49 -0600 Message-ID: Subject: Re: RFC: Use of VOP_ALLOCATE() by NFSV4.2 nfsd To: Rick Macklem Cc: FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4HS3Dz6ngKz4nSl X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Sat, Oct 9, 2021 at 11:57 PM Rick Macklem wrote: > > Alan Somers wrote: > >On Sat, Oct 9, 2021 at 7:13 PM Rick Macklem wrote: > >> > >> Hi, > >> > >> I ran into an issue this week during the nfsv4@ietf.org's testing event. > >> UFS - supports VOP_ALLOCATE() by using vop_stdallocate(). > >> ZFS - just return EINVAL for VOP_ALLOCATE(). > >> > >> An NFSv4.2 server can either support Allocate or not, but it has to be > >> for all exported file systems. > > > >That seems like a protocol bug to me. Could this be fixed in a future > >NFS revision? > Who knows. I don't see any interest in a 4.3. 4.2 is extensible, but I think > this is now "cast in stone". > > >> > >> This leads me to a couple of questions: > >> - Is there a good reason for not using vop_stdallocate() for ZFS? > > > >Yes. posix_fallocate is supposed to guarantee that subsequent writes > >to the file will not fail with ENOSPC. But ZFS, being a copy-on-write > >file system, cannot possibly guarantee that. See SVN r325320. > However, vop_stdallocate() just does VOP_WRITE()s to the area (with > bytes of data all zeros). Wouldn't that satisfy the criteria? No. It works for UFS, which is an overwriting file system. But for ZFS, when the user comes back later to rewrite those same offsets, ZFS will actually allocate new LBAs for them. > > >> - Should I try and support both file system types via vop_stdallocate() > >> or not support Allocate at all? > > > >Since you can't possibly support it for ZFS (not to mention other file > >systems like fusefs) you'll have to not support it at all. > It does sound like not supporting it is the best alternative. > > rick > > > > > Btw, as a bit of an aside, "cc" uses posix_fallocate() and in weird ways, > > such as offset=0, len=1. Why, I have no idea? > > > > Thanks in advance for any comments, rick > > From nobody Sun Oct 10 13:57:07 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id A834617E0BA9 for ; Sun, 10 Oct 2021 13:57:19 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660058.outbound.protection.outlook.com [40.107.66.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HS3QR3VWQz4q7w; Sun, 10 Oct 2021 13:57:19 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bSy/iyFowW1527wzV3HxfhjWWSXTaFzkfKJkUcSRccYIIXKOm8lTaVCGCXjY9aaRWRWdWk1TaMKOjotMQDFqut98dQuEBGrwFX/YGvZWj4rZhuVW9ZSFHXNr6gyoIPM1zns61Y9nWC8YKCoBvvzCUu4ZhJtvqIAfxEzgM+CUbdl3+7eJZkMiGTOXP01/RplL+Z1JC8Z8hWHnem+SahZwPiWArTvge9H2tz9+TwXOZLXu0bGJbsjtpWvGXbUFwRwn/tLtXCYd1VNxZX7CIOlGJKSKitpQbC6l4lc1qhZRV20tZvvYVD25BjoSw2gjWlKRO46V+nCFv9ur5XgDov3p3g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=URDXdzAjWv7tXwiW+AdHlWu1F9bG6313oUzYVlOUv9Q=; b=gqTrxYjyK8bdUXr7r2PCLW6vvO14GZJsOBYvmyUOaIJsP/EJKFxRB7q63dZp2ezck9lyCHMiOoUeyM6KgCeGB8meFhb+IALL7z896J9ewtfRXDsnMuZ9mFNda4h2C8QEvJ2R5bvx3Njy44FUXAMbvcMwpvk8IDHWaofDkcjT6UU8mrT96LzsAPL/WQ0g1N4ty2mQLWFuMz9Drnaxec99biIMcBf03AI1bUrKJigfzFVMa4WDuJe+P3J1WffLDl+TD67EZGXyWPlkDXFSEJQNF23LXGv8Hte9rMH1glS4jf9OoXhm85PSdacBAIbEpdUB2lkwlpYJJKSA8a3tczHEzA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=URDXdzAjWv7tXwiW+AdHlWu1F9bG6313oUzYVlOUv9Q=; b=MFoBr6ZFdd8kWAWmf47CKWDzRoIIXopYGnW84+S0fYzhpzblWBD/ecDZ66rJYFN8R8xcZk35N67LwAveEz6jqHD4J/Qyk+K2CUiMQM0e35EXucW36viYOAOOEE+Q7oZUadHJJPuNjuePIsWCn+qiOiMBOQYbrsBVWfpb6Sn4xjetFb0m7alnv9Grh3CN1EMiM/7A3uIXzN65CHnvlmRjVipxXZAJ7NF3I4pZkeJGagr2uQ5RYQgSP2+URqvYu/xSFEm8+1cti/QgVOVSuaNRou1t2YxWAehcoeQJDGvMXwPPagGo7yb6Ndy/WoNwiunhZWlPl44xcVRmi/dxWRGg0w== Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:19::29) by YQBPR0101MB2083.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:3::28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.25; Sun, 10 Oct 2021 13:57:12 +0000 Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::7091:13ac:171f:1c12]) by YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::7091:13ac:171f:1c12%5]) with mapi id 15.20.4587.025; Sun, 10 Oct 2021 13:57:07 +0000 From: Rick Macklem To: Alan Somers CC: FreeBSD Current Subject: Re: RFC: Use of VOP_ALLOCATE() by NFSV4.2 nfsd Thread-Topic: RFC: Use of VOP_ALLOCATE() by NFSV4.2 nfsd Thread-Index: AQHXvXMbM0Hsf8N9W0qQA3mOobhhb6vLmYKAgAAg6CeAAIXKgIAAAJEb Date: Sun, 10 Oct 2021 13:57:07 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: fe23a23d-f9d1-3069-f846-fc1b8270cad2 x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b66c9611-f0bc-49f6-d618-08d98bf5d8dc x-ms-traffictypediagnostic: YQBPR0101MB2083: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: WRmB/FZp6gyPaSPOlzGa0fFd8pc7sDJ/8Nzuq145qq56f9oL9oqS1DCDsPrl5CJaokTigJxS0dAHluxrbtV5/1Du7cuSXr+A9BVWq32/OhZwa1ir8gg4bZI1N1PhuHvlH7vI7drnl2QT9e/YrAvCXwzIxFdFedWCFoleP3u2zdXC2C5kzm+Q2G/Me4vaC1Gy3M+zR6t0cxFYyw/eIfeOejbRdKvlli65icOG6iiWKZOfh9ZBE6gWKJZTOcE/sGB+VoSdzTxM6MbGbTzelvxv/AXmRuf4spBebsrQlrE1ANiJw4gePyUs0QKiBAZS3bm8HZ4XqZ5XfeWLzAHatUW6Ly/RuVusT1zp0NUeWCraedWgps//4Ph3aKpsJOoCOlOr5cQkrvmRAJj7CuUgJ3guYdnOtaj/tniOV8K2itD/azNp7ytcX6EPN1OXVyNItq0XIet+SP0R1uuaos/ArUcd89ILi341+O19f/JK6fcq4/BaI9G5dZFgd4YR8JipuFZaIADYamDFU1qyoMI7eCRpyQNuA67u8mbRJbAOEQ6qjc3f7RNu5nj5/KLPJOOAovmoLDzKD5EgFp4BX+EQE9QO7STZ8Re+G8hifs2SAyROvXAAPKyfRzz38YRFZlj7eUJt9JmX3AvCbuuc9gETehbA4e2RM8g5jn9hbIR6uwGWACv0JZPRa1nI2DfmQS1/GJDLQziqTtaBJsycJU5vYsEhOQ== 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)(38070700005)(33656002)(6506007)(9686003)(66556008)(86362001)(6916009)(66446008)(4326008)(122000001)(38100700002)(7696005)(316002)(786003)(66476007)(8676002)(5660300002)(52536014)(55016002)(2906002)(508600001)(71200400001)(64756008)(76116006)(8936002)(91956017)(66946007)(186003)(450100002);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?Qi+wDVwHS/wRzvkjLpVswqnxhY1sfoJ5mxrlKvqEIymVLPPkf6j2uA5TCr?= =?iso-8859-1?Q?JhWDrvpBjLk9zurxdu3ai/trLz8TT+5Kho3CVBXe8iEdRBaa901Nn83Xm0?= =?iso-8859-1?Q?qiEIHLUeRYQmu3GyZcL4zh9/YctzEuDMGy8XSSj2fw728apDI9w18IMtk4?= =?iso-8859-1?Q?ODbzLeDzGrMdt7PW8Gm+gaTsuDZ7OnEfiUAclX7Yp27MkfbWyzA2DLgMjd?= =?iso-8859-1?Q?LmShqTtJlBwVq0btzVnAHOLEUxpZ7zo8TOYGRT8whVxi4Pb2vW4/HOIBAZ?= =?iso-8859-1?Q?8Xfvjtoov7k3Ji+xy6kHcDXFvoeL2dWfB5s4wrqFQ4ZLYno5r0+jo+jpIU?= =?iso-8859-1?Q?xiQ6MTnYE+hS0SctHr3Vxdlr0rfdwy1zGwxjoU8BrubOUQmt3Z5tdvSq/U?= =?iso-8859-1?Q?zZg1rWay+hFagz5PI8e5sfez4anjvscr0RsA5wxxj3GDh4C9/YsFGOA0Dp?= =?iso-8859-1?Q?XklwFgkC/ZYBrGuCr8J+fcg8PosRzkyB8lB5bRF5LDKYo30y50zZOXHOOu?= =?iso-8859-1?Q?K2AQoEHQZLiY/6XXvaeyM7hifl5w8y3Dq0Dm3VX/8GcH4nJKPBaMJAdtWT?= =?iso-8859-1?Q?hFWUoJMyt2x+e16NxGTzDgmmOcqYXdO95v8NpJXgMAJdA0whWKv7/e3309?= =?iso-8859-1?Q?ra9wAqcaskodyPT2UIxnglzh38+VSN+dcfOKWpNxzA749XFtdKGWcSHyMU?= =?iso-8859-1?Q?k1RUtDGPl1x6qMnKVubunto8vHjc7Q0hoQo7OvTVOoCbyCkOjpm2WI54/u?= =?iso-8859-1?Q?oCbQkWlElGPtsqtU5j+7Dy2gOzmQtnNyMLn0uGcwGirbRRqfz71/J+RKK1?= =?iso-8859-1?Q?emsef45ZKcsGLo1M+RhENAgzP/Kk+kj0nGOOHt/AA3m7NYP/7cRbJQJdBu?= =?iso-8859-1?Q?vvTMgJvCiGoCgr+WxNuhXJQwn76vqKaVNir9izuhcWg7XD0RiiNkeG658x?= =?iso-8859-1?Q?S4AIZSfmVnPKx8sVtTC2OYfnmIY/M1D9oFyGAqMM3zKbKflBW8LghtSQ+U?= =?iso-8859-1?Q?n36I8UbyzAdA402w5nSjUradzh4eGfjOSNb8jaQm8Urh1PaEQ/a+R0Gcbx?= =?iso-8859-1?Q?VOXKcwpbgtFU5oLDTV9midij72DJprIfmKJqg7+MmH6JZdutRhhu/kWuvU?= =?iso-8859-1?Q?PHltFlKTqNwmkgrGsv2YnJp2QsK4TMqiNlSYOSDUGJs8xHh4YninRCAYKM?= =?iso-8859-1?Q?kk6+bYKME3u/nVt7ofbZK/oJDtqPc21ReHJhvUT/6yno6Pujed+0yK6dWm?= =?iso-8859-1?Q?al96iTUumrouWIR+NGHxGNze0NHciK+aM37Dmr7cCVlcDiJ5pIqQUjr1qX?= =?iso-8859-1?Q?sn1Kc2USlcSv+Q3WYUVKqGOa60cvRg6/wDlqcfUE+tx54lV/HmPEB1SVDP?= =?iso-8859-1?Q?qDQgrdCmgC7/kmBAuE68H14NVDCNQInBIpIXNs5+Esglp3zdgyWp4=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: b66c9611-f0bc-49f6-d618-08d98bf5d8dc X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Oct 2021 13:57:07.0146 (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: C7oDStoAzp54P/jbF2HCBg2I6IVkjhOJ4NaJdqU1MVz9c+xxLLySeY0GB7a7cVGuJE5RYQ5ycC8Tfj34hXwxgg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQBPR0101MB2083 X-Rspamd-Queue-Id: 4HS3QR3VWQz4q7w X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N Alan Somers wrote:=0A= [stuff snipped]=0A= >Rick Macklem wrote:=0A= > >Alan Somers wrote:=0A= > > >Yes. posix_fallocate is supposed to guarantee that subsequent writes= =0A= > > >to the file will not fail with ENOSPC. But ZFS, being a copy-on-write= =0A= > > >file system, cannot possibly guarantee that. See SVN r325320.=0A= > > However, vop_stdallocate() just does VOP_WRITE()s to the area (with=0A= > > bytes of data all zeros). Wouldn't that satisfy the criteria?=0A= >=0A= > No. It works for UFS, which is an overwriting file system. But for=0A= > ZFS, when the user comes back later to rewrite those same offsets, ZFS=0A= > will actually allocate new LBAs for them.=0A= Eighto. I get it now.=0A= =0A= Looks like I must disable it in the server, unless there is a way to enable= =0A= it on a per file system basis (which I don not believe is the case for NFSv= 4.2,=0A= although that isn't completely clear from the RFC, which says each operatio= n=0A= is optional, but does not mention "per file system").=0A= =0A= Thanks everyone, for your replies, rick=0A= =0A= >=0A= > >> - Should I try and support both file system types via vop_stdallocate(= )=0A= > >> or not support Allocate at all?=0A= > >=0A= > >Since you can't possibly support it for ZFS (not to mention other file= =0A= > >systems like fusefs) you'll have to not support it at all.=0A= > It does sound like not supporting it is the best alternative.=0A= >=0A= > rick=0A= >=0A= > >=0A= > > Btw, as a bit of an aside, "cc" uses posix_fallocate() and in weird way= s,=0A= > > such as offset=3D0, len=3D1. Why, I have no idea?=0A= > >=0A= > > Thanks in advance for any comments, rick=0A= > >=0A= From nobody Sun Oct 10 14:43:06 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4E6E817E6E69 for ; Sun, 10 Oct 2021 14:43:50 +0000 (UTC) (envelope-from dnebdal@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 4HS4S6172mz4vYH; Sun, 10 Oct 2021 14:43:50 +0000 (UTC) (envelope-from dnebdal@gmail.com) Received: by mail-wr1-x435.google.com with SMTP id e12so46903003wra.4; Sun, 10 Oct 2021 07:43:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lINrFD7osMfw3wXWmyr8q6TwmM2BjFyVboLcdtmuSzM=; b=YGugEk0Ln9Ys70uWoBE8lE01kmqiBQTXZCy3J5r1QTe7OJ8ii39SpoRia+rW/DdW+6 /bki6tLGv3axM7rT2MzKf5fibpDZl2DJogvNoVsa8+PGT0HAd7kJB/SRUadgGzsaZ//5 sImjwX5s+COBGarHRXNwKx7bHiHEo6i6/0dGSpNBnV8PRe51HzfvXtD1iaT8uSuuTP9I I97zmMSIOFqEC/TmG0IzVYfNT/s0o5EbJEzVAGW2QpYy7LJx7AW56d1MGlLPsi6Btyaw juDozYAhIr8mPBbdkUAj2oU1EWJonG7J47Ft8B58JQUbozI88wpWBTidSpymmmzz10rP a11g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lINrFD7osMfw3wXWmyr8q6TwmM2BjFyVboLcdtmuSzM=; b=6BfdDm6E6cZwiQS1RuWJV0nawBv+0klvMHs7XPfZiDYByqtqbA3kGXclB6NaJSx3HD ApHDiZ+ImoZemgoV5ZF3oR34dZEd/In9YO62byyuy9D0wn7b91CcOLcZdhAD8YwLM3IK OcU1W0VaKoJmf17hYBD3u/j1mlHbL4U5BxbS9RFYvQxFsqjQaXKwDSpxllAWfB70d5yl TQROkQKdpr2pZNZ9PdyFEbJUThbBFBpvFObeKL0DWRvIfMU4wp1d2YmHNUwB1BgLPyQ8 lurawhnfdElM1M7Yj2FdFmbl9k/IHUhmqLMGQLKyYRKkIdgweogVfg8NmwwUrJGc/GMa 4piA== X-Gm-Message-State: AOAM532Sb1RXaj569MGoQ0jD/wRrQqs2bTBNFXkL5FH0vnksgVhAQ442 RlnafLI4r7gu0u/ztpfwnaVMXay73vT8tAlJ/Yq9jbXzGbx4cg== X-Google-Smtp-Source: ABdhPJwR0rV96lBqvjBOxs5HezEW1Au8DuXoDNKg95fMj1cVDHc3Ua+jMAXeaGKDAxj/ATIJPztUKxJ4HCcr7i64bgk= X-Received: by 2002:a1c:4c17:: with SMTP id z23mr15978079wmf.61.1633877022200; Sun, 10 Oct 2021 07:43:42 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <20211010040637.3fw7q6nl7gn7aum4@aniel.nours.eu> <20211010044111.mvzuepff34ztqctq@aniel.nours.eu> <20211010054519.ennyyt3qba3reaop@aniel.nours.eu> In-Reply-To: <20211010054519.ennyyt3qba3reaop@aniel.nours.eu> From: Daniel Nebdal Date: Sun, 10 Oct 2021 16:43:06 +0200 Message-ID: Subject: Re: clang/llvm-tblgen --- ld: error: undefined symbol: setupterm To: Baptiste Daroussin Cc: Warner Losh , Kyle Evans , Konstantin Belousov , Dimitry Andric , FreeBSD User , FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4HS4S6172mz4vYH X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Sun, 10 Oct 2021 at 07:46, Baptiste Daroussin wrote: > > On Sat, Oct 09, 2021 at 11:33:54PM -0600, Warner Losh wrote: > > On Sat, Oct 9, 2021 at 11:29 PM Kyle Evans wrote: > > > > > On Sun, Oct 10, 2021 at 12:18 AM Warner Losh wrote: > > > > > > > > On Sat, Oct 9, 2021 at 10:45 PM Warner Losh wrote: > > > > > > > > > > > > > > > > > > > On Sat, Oct 9, 2021 at 10:41 PM Baptiste Daroussin > > > > > wrote: > > > > > > > > > >> On Sun, Oct 10, 2021 at 06:06:37AM +0200, Baptiste Daroussin wrote: > > > > >> > On Sun, Oct 10, 2021 at 02:52:58AM +0300, Konstantin Belousov wrote: > > > > >> > > On Sat, Oct 09, 2021 at 05:29:39PM -0600, Warner Losh wrote: > > > > >> > > > On Sat, Oct 9, 2021, 5:15 PM Konstantin Belousov < > > > > >> kostikbel@gmail.com> > > > > >> > > > wrote: > > > > >> > > > > > > > >> > > > > On Sat, Oct 09, 2021 at 04:47:35PM -0600, Warner Losh wrote: > > > > >> > > > > > On Sat, Oct 9, 2021 at 11:09 AM Dimitry Andric < > > > dim@freebsd.org> > > > > >> wrote: > > > > >> > > > > > > > > > >> > > > > > > On 9 Oct 2021, at 15:40, Warner Losh > > > wrote: > > > > >> > > > > > > > > > > > >> > > > > > > > On Sat, Oct 9, 2021, 5:59 AM Dimitry Andric < > > > > >> dim@freebsd.org> wrote: > > > > >> > > > > > > > On 9 Oct 2021, at 13:37, Dimitry Andric > > > > > > > >> wrote: > > > > >> > > > > > > > > > > > > >> > > > > > > > > On 9 Oct 2021, at 09:46, FreeBSD User < > > > > >> freebsd@walstatt-de.de> > > > > >> > > > > wrote: > > > > >> > > > > > > > >> > > > > >> > > > > > > > >> On recent CURRENT (FreeBSD 14.0-CURRENT #2 > > > > >> > > > > main-n249971-0525ece3554e: > > > > >> > > > > > > > >> Fri Oct 8 15:17:34 CEST 2021 amd64) building of an > > > > >> 13-STABLE > > > > >> > > > > based > > > > >> > > > > > > > >> appliance failed very early in the build process of > > > the > > > > >> 13-STABLE > > > > >> > > > > > > > >> sources as shown below. 13-STABLE is most recent, > > > since > > > > >> the > > > > >> > > > > sources > > > > >> > > > > > > are > > > > >> > > > > > > > >> fetched every time the build process is triggered. > > > > >> > > > > > > > > ... > > > > >> > > > > > > > >> > > > > >> > > > > > > > > > > >> > > > /pool/home/ohartmann/Projects/router/router/apu2c4/src/tools/install.sh > > > > >> > > > > > > > >> -s -o root -g wheel -m 555 compile_et > > > > >> > > > > > > > >> /pool/home/ohartmann/Projects/router/router/apu2 > > > > >> > > > > > > > >> > > > > >> > > > > > > > > > > >> > > > > > > > > >> > > > c4/world/amd64/ALERICH_13-STABLE_amd64/pool/home/ohartmann/Projects/router/router/apu2c4/src/amd64.amd64/tmp/legacy/usr/bin/compile_et > > > > >> > > > > > > > >> --- _bootstrap-tools-usr.bin/clang/llvm-tblgen --- > > > ld: > > > > >> error: > > > > >> > > > > > > undefined > > > > >> > > > > > > > >> symbol: setupterm > > > > >> > > > > > > > >>>>> referenced by Process.cpp > > > > >> > > > > > > > >>>>> > > > > >> > > > > > > > > > Process.o:(llvm::sys::Process::FileDescriptorHasColors(int)) > > > > >> > > > > > > > > > > > > >> > > > > > > > > It is complaining about ncurses functions; it seems > > > that > > > > >> even > > > > >> > > > > though > > > > >> > > > > > > the link step gets -lncursesw added, it still is not able > > > to > > > > >> find the > > > > >> > > > > > > symbol: > > > > >> > > > > > > > > > > > >> > > > > > > > Okay, this is because recently on -CURRENT, libtinfow > > > got > > > > >> split off > > > > >> > > > > from > > > > >> > > > > > > > libncursesw: > > > > >> https://cgit.freebsd.org/src/commit/?id=396851c20aebd > > > > >> > > > > > > > > > > > >> > > > > > > > This affects such cross-builds obviously, and manually > > > > >> adding > > > > >> > > > > -ltinfow > > > > >> > > > > > > > to the link command line makes it link correctly. > > > > >> > > > > > > > > > > > >> > > > > > > > However, the 396851c20aebd commit is probably not > > > suitable > > > > >> for > > > > >> > > > > MFC'ing > > > > >> > > > > > > > to stable/13. Maybe we need to put some kind of kludge > > > in > > > > >> > > > > > > > share/mk/src.libnames.mk for this, or in the top-level > > > > >> > > > > Makefile.inc1? > > > > >> > > > > > > > > > > > >> > > > > > > > Baptiste, any ideas? :) > > > > >> > > > > > > > > > > > >> > > > > > > > Add setupterm() to libegacy as a nop. > > > > >> > > > > > > > > > > >> > > > > > > That's not enough I think, it requires more ncurses > > > functions > > > > >> than just > > > > >> > > > > > > setupterm. And it actually calls them and checks the > > > return > > > > >> values too, > > > > >> > > > > > > IIRC. :) > > > > >> > > > > > > > > > > >> > > > > > > > > > >> > > > > > int setupterm(const char *t, int fd, int *errptr) { return > > > OK; } > > > > >> > > > > > int tigetnum(const char *t) { return 0; } > > > > >> > > > > > TERMINAL *set_curterm(TERMINAL *t) { return NULL; } > > > > >> > > > > > int del_curterm(TERMINAL *t) { return OK; } > > > > >> > > > > > > > > > >> > > > > > should do the trick. I'll see just how crazy an idea this > > > might > > > > >> be > > > > >> > > > > > since we're trying to get the first stage tool to work on a > > > > >> -current > > > > >> > > > > > host. the only thing that clang is really using is tigetnum > > > to > > > > >> see > > > > >> > > > > > if the terminal has color. Returning 0 tells it no. > > > > >> > > > > > > > > > >> > > > > > Or we could contrive, during bootstrap, to ensure that > > > > >> > > > > > LLVM_ENABLE_TERMINFO is not defined. Nobody ever needs > > > > >> > > > > > color error messages. They are nice to have, sure, but are > > > not > > > > >> > > > > > strictly needed if the alternative is monochrome error > > > messages > > > > >> > > > > > while building the system. There's already an ifdef > > > protecting > > > > >> it: > > > > >> > > > > > > > > > >> > > > > > /* Define if the setupterm() function is supported this > > > > >> platform. */ > > > > >> > > > > > #if defined(__FreeBSD__) > > > > >> > > > > > /* > > > > >> > > > > > * This is only needed for terminalHasColors(). When > > > disabled > > > > >> LLVM falls > > > > >> > > > > > back > > > > >> > > > > > * to checking a list of TERM prefixes which is sufficient > > > for a > > > > >> > > > > bootstrap > > > > >> > > > > > tool. > > > > >> > > > > > */ > > > > >> > > > > > #define LLVM_ENABLE_TERMINFO 1 > > > > >> > > > > > #endif > > > > >> > > > > > > > > > >> > > > > > It would be easy enough to add a && > > > > >> !defined(LLVM_BOOTSTRAP_BUILD) > > > > >> > > > > > or similar. > > > > >> > > > > > > > > >> > > > > I do not quite understand how would it help. > > > > >> > > > > You need to add this to HEAD sources back in time, not to the > > > > >> current > > > > >> > > > > sources. > > > > >> > > > > > > > > >> > > > > > > > >> > > > Once merged, this would get stable building on current. But not > > > > >> older > > > > >> > > > versions of stable, it is true. It's worth doing for that reason > > > > >> alone > > > > >> > > > unless there's something clever we've not thought of yet with > > > the > > > > >> current > > > > >> > > > host. > > > > >> > > > > > > >> > > We can put somewhere a patch and add instructions how to use it to > > > > >> patch > > > > >> > > older HEADs and stable. May be instructions and the reference to > > > the > > > > >> patch > > > > >> > > file should go into UPDATING 20211004 entry. > > > > >> > > > > > >> > It fails to link because the bootstrap tools are built statically if > > > > >> they were > > > > >> > linked dynamically that would solve the situation, because > > > > >> libncursesw.so is a > > > > >> > linkscript which does the right thing. > > > > >> > > > > > >> > Stupid question, why are bootstrap tools statically linked in the > > > first > > > > >> place? > > > > >> > If we remove -DNO_SHARED from the BARGS, it compiles perfectly fine. > > > > >> > > > > > >> > Imho we should remove the static linking here, the other way would > > > be to > > > > >> > provide a "flat" libncursesw.a for those cases on CURRENT. which I > > > > >> don't know how to > > > > >> > provide without breaking things even more. > > > > >> > > > > > >> > Best regards, > > > > >> > Bapt > > > > >> > > > > >> the reason being -DNO_SHARED is speeding up the bootstrap, so > > > probably we > > > > >> need > > > > >> to either investigate make ncurses a bootstrap lib for clang, or > > > having > > > > >> kind of > > > > >> an equivalent of what the linker script is doing for libncursesw.so > > > but > > > > >> for > > > > >> libncursesw.a. > > > > >> > > > > > > > > > > We build so few libraries (usually none) that we can ditch this > > > > > optimization for > > > > > the upgrades (the libraries built are usually tiny). > > > > > > > > > > > > > Though it's still a 'patch the past' path forward... The fix is trivial > > > to > > > > describe. > > > > > > > > > > It doesn't sound like there's any need to 'patch the past'... the > > > status quo is that the static libncursesw is effectively "broken" > > > because consumers need to know to link to libtinfow. If the linker > > > script idea works (which it seems like it will) then it's a non-issue; > > > either we're building on a system that has the all-in-one libncursesw > > > or we're building against a linker script that also does the right > > > thing. > > > > > > > Yea, the linker script notion is the only thing that's talked about so > > far that's something where we don't need to patch the past. The > > old tools know how to cope with the linker script and will bring the > > right things in. My comments were about removing -DNO_SHARED... > > > > We should remove -DNO_SHARED as well from the bootstrap tools, > > but that's a separate issue if the linker script works. > > > > Warner > > This https://reviews.freebsd.org/D32435 should make freebsd stable 12 and 13 > buildable out of box again on freebsd 14. > > Best regards, > Bapt > I don't know if this is the right place to jump in, but I suspect this is a related issue? I'm trying to do the opposite - building 14 on a 13-STABLE machine. It fails when trying to build ncurses: root@p14s-bsd:/usr/src # uname -v FreeBSD 13.0-STABLE #0 stable/13-n247584-fdbbd118faa: Sun Oct 10 03:25:38 CEST 2021 root@p14s-bsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC root@p14s-bsd:/usr/src # git pull Already up to date. root@p14s-bsd:/usr/src # git status On branch main Your branch is up to date with 'origin/main'. nothing to commit, working tree clean root@p14s-bsd:/usr/src # make buildworld > build.log (...) The full log is at http://eurostar.nebdal.no/build.log It's all variations over this: ===> lib/ncurses/ncurses (obj,all,install) Building /usr/obj/usr/src/amd64.amd64/lib/ncurses/ncurses/lib_color.o /usr/src/contrib/ncurses/ncurses/base/lib_color.c:192:5: error: implicit declaration of function '_nc_tiparm' is invalid in C99 [-Werror,-Wimplicit-function-declaration] TIPARM_1(set_a_background, bg), ^ /usr/src/contrib/ncurses/include/nc_tparm.h:81:23: note: expanded from macro 'TIPARM_1' #define TIPARM_1(s,a) _nc_tiparm(1,s,a) ^ /usr/src/contrib/ncurses/ncurses/base/lib_color.c:192:5: error: incompatible integer to pointer conversion passing 'int' to parameter of type 'const char *' [-Werror,-Wint-conversion] TIPARM_1(set_a_background, bg), ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ /usr/src/contrib/ncurses/include/nc_tparm.h:81:23: note: expanded from macro 'TIPARM_1' #define TIPARM_1(s,a) _nc_tiparm(1,s,a) ^~~~~~~~~~~~~~~~~ -DanielN From nobody Sun Oct 10 20:15:44 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id D40F517F7ADF for ; Sun, 10 Oct 2021 20:15:46 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (smtp.digiware.nl [176.74.240.9]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HSCq64rNhz4VHL; Sun, 10 Oct 2021 20:15:46 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from router10g.digiware.nl (localhost.digiware.nl [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id 7B4483D307; Sun, 10 Oct 2021 22:15:39 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=digiware.nl; s=medusa-2017; t=1633896939; bh=fte4tmqDdgs8j8nsePt6irr6vY4HRlMlIlYUcpzCbMs=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=QgtLPhkFru4H7H122N62J3z6uVM8rbBqkMtKcxUCFToK2Z6c/XhaDDxhJr907+ckk ViRmP/j+nTST186ckVxaqws3EMtJm6WlJHLAGP7Y+dPpFuzx9CcNTclrCt3x6247Vx oChV6ixTmfTd89bJN/KXYPgc1kank+XV/sS9haDJodVEWSR1rdi4G0vl2PEmjYzGjq ltCOGWLwX9WcX2kKwIdEdg3joWvL+DarXzrN0L/btooSIYIz9H7Pv6gn1T2HD6K/Ti sQV/BZXfFHpP6z7iXccgdb7qM0DutQ0pRXR4NWdvmh2AzHQo8f/l+2QaxR6zc2tP6z oHKMD75ogRxgw== X-Virus-Scanned: amavisd-new at digiware.nl Received: from smtp.digiware.nl ([127.0.0.1]) by router10g.digiware.nl (router10g.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JWDqjiuvmxKF; Sun, 10 Oct 2021 22:15:39 +0200 (CEST) Received: from [192.168.10.9] (vaio [192.168.10.9]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id E334D3D14A; Sun, 10 Oct 2021 22:15:38 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=digiware.nl; s=medusa-2017; t=1633896938; bh=fte4tmqDdgs8j8nsePt6irr6vY4HRlMlIlYUcpzCbMs=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=kwawD3gmS92y6f9w8zogbDlsCJlzZyaWB8byk4yZ/0wgDPFTFz21whALSXP7zHgWY r6MIQ4lwvozs1gvzwQc/GzbvVk0vzqqpokwyPQMBdMUc2+oxJHPfjpMWJ6sWpzLjOg 2YQh2nhERKFEj2TKgzmPnfLgnMhOxgTBlhVL2wRZvw9zO9h3sWk93LAnQ51+iLMEsY DmFHbW9kYs5Bq2J/To3xN/gl31vcdjcdUsIzuvlmewA6ayxa1rl4r0IhdofzVJSf2h ozhkcLuPBM68XNDu/k4mque4Uo6uXH6LgWbqiwXATrvYKfO3YLQ2tzsG0R8CjuVoKs +OXbXb7YlJ9Bw== Subject: Re: RFC: Use of VOP_ALLOCATE() by NFSV4.2 nfsd To: Rick Macklem , Alan Somers Cc: FreeBSD Current References: Message-ID: Date: Sun, 10 Oct 2021 22:15:44 +0200 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0 Thunderbird/78.14.0 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Rspamd-Queue-Id: 4HSCq64rNhz4VHL X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: wjw@digiware.nl From: Willem Jan Withagen via freebsd-current X-Original-From: Willem Jan Withagen X-ThisMailContainsUnwantedMimeParts: N On 10-10-2021 07:57, Rick Macklem wrote: > >>> This leads me to a couple of questions: >>> - Is there a good reason for not using vop_stdallocate() for ZFS? >> Yes. posix_fallocate is supposed to guarantee that subsequent writes >> to the file will not fail with ENOSPC. But ZFS, being a copy-on-write >> file system, cannot possibly guarantee that. See SVN r325320. > However, vop_stdallocate() just does VOP_WRITE()s to the area (with > bytes of data all zeros). Wouldn't that satisfy the criteria? > I had the same problem in Ceph, where a guaranteed writable space is required for keeping a log of modifications to the system. Not having this space might case loss of data. Writing al zero's is probably even worse on filesystems that have compression set. Almost nothing is allocated, and so no guarantee at all. Next trick wass to write random data, but then you run into the problem signaled by Alan and Warner. New writes will need free space, since the CoW nature. Solution was to actually create a specific zpool just for this. But that will not help you with NFS 4.2 I guess --WjW From nobody Sun Oct 10 20:17:40 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 176E317F8D32 for ; Sun, 10 Oct 2021 20:17:45 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HSCsN53yzz4WQX; Sun, 10 Oct 2021 20:17:44 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: from aniel.nours.eu (nours.eu [IPv6:2001:41d0:8:3a4d::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: bapt) by smtp.freebsd.org (Postfix) with ESMTPSA id 14E3E2EFE9; Sun, 10 Oct 2021 20:17:44 +0000 (UTC) (envelope-from bapt@FreeBSD.org) Received: from dummy.faircode.eu (10.246.39.62.rev.sfr.net [62.39.246.10]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by aniel.nours.eu (Postfix) with ESMTPSA id 8435761EBC; Sun, 10 Oct 2021 22:17:41 +0200 (CEST) Date: Sun, 10 Oct 2021 20:17:40 +0000 (UTC) From: Baptiste Daroussin To: Daniel Nebdal Cc: Warner Losh , Kyle Evans , Konstantin Belousov , Dimitry Andric , FreeBSD User , FreeBSD CURRENT Message-ID: <339723c9-24d1-403e-bea8-a6978967db95@FreeBSD.org> In-Reply-To: References: <20211010040637.3fw7q6nl7gn7aum4@aniel.nours.eu> <20211010044111.mvzuepff34ztqctq@aniel.nours.eu> <20211010054519.ennyyt3qba3reaop@aniel.nours.eu> Subject: Re: clang/llvm-tblgen --- ld: error: undefined symbol: setupterm List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Correlation-ID: <339723c9-24d1-403e-bea8-a6978967db95@FreeBSD.org> X-ThisMailContainsUnwantedMimeParts: N 10 oct. 2021 16:43:52 Daniel Nebdal : > On Sun, 10 Oct 2021 at 07:46, Baptiste Daroussin wrote= : >> >> On Sat, Oct 09, 2021 at 11:33:54PM -0600, Warner Losh wrote: >>> On Sat, Oct 9, 2021 at 11:29 PM Kyle Evans wrote: >>> >>>> On Sun, Oct 10, 2021 at 12:18 AM Warner Losh wrote: >>>>> >>>>> On Sat, Oct 9, 2021 at 10:45 PM Warner Losh wrote: >>>>> >>>>>> =E2=80=A6 >>>> dim@freebsd.org> >>>>>> =E2=80=A6 >>>> wrote: >>>>>> =E2=80=A6 >>>>> >>>>>> =E2=80=A6 >>>> the >>>>>> =E2=80=A6 >>>> since >>>>>> =E2=80=A6 >>>> /pool/home/ohartmann/Projects/router/router/apu2c4/src/tools/install.s= h >>>>>> =E2=80=A6 >>>> c4/world/amd64/ALERICH_13-STABLE_amd64/pool/home/ohartmann/Projects/ro= uter/router/apu2c4/src/amd64.amd64/tmp/legacy/usr/bin/compile_et >>>>>> =E2=80=A6 >>>> ld: >>>>>> =E2=80=A6 >>>> Process.o:(llvm::sys::Process::FileDescriptorHasColors(int)) >>>>>> =E2=80=A6 >>>> that >>>>>> =E2=80=A6 >>>> to >>>>>> =E2=80=A6 >>>> got >>>>>> =E2=80=A6 >>>> suitable >>>>>> =E2=80=A6 >>>> in >>>>>> =E2=80=A6 >>>> functions >>>>>> =E2=80=A6 >>>> return >>>>>> =E2=80=A6 >>>> OK; } >>>>>> =E2=80=A6 >>>> might >>>>>> =E2=80=A6 >>>> to >>>>>> =E2=80=A6 >>>> not >>>>>> =E2=80=A6 >>>> messages >>>>>> =E2=80=A6 >>>> protecting >>>>>> =E2=80=A6 >>>> disabled >>>>>> =E2=80=A6 >>>> for a >>>>>> =E2=80=A6 >>>> the >>>>>> =E2=80=A6 >>>> the >>>>>> =E2=80=A6 >>>> first >>>>>> =E2=80=A6 >>>> be to >>>>>> =E2=80=A6 >>>> probably we >>>>>> =E2=80=A6 >>>> having >>>>>> =E2=80=A6 >>>> but >>>>>> =E2=80=A6 >>>>> >>>>> Though it's still a 'patch the past' path forward... The fix is trivi= al >>>> to >>>>> describe. >>>>> >>>> >>>> It doesn't sound like there's any need to 'patch the past'... the >>>> status quo is that the static libncursesw is effectively "broken" >>>> because consumers need to know to link to libtinfow. If the linker >>>> script idea works (which it seems like it will) then it's a non-issue; >>>> either we're building on a system that has the all-in-one libncursesw >>>> or we're building against a linker script that also does the right >>>> thing. >>>> >>> >>> Yea, the linker script notion is the only thing that's talked about so >>> far that's something where we don't need to patch the past. The >>> old tools know how to cope with the linker script and will bring the >>> right things in. My comments were about removing -DNO_SHARED... >>> >>> We should remove -DNO_SHARED as well from the bootstrap tools, >>> but that's a separate issue if the linker script works. >>> >>> Warner >> >> This https://reviews.freebsd.org/D32435 should make freebsd stable 12 an= d 13 >> buildable out of box again on freebsd 14. >> >> Best regards, >> Bapt >> > > I don't know if this is the right place to jump in, but I suspect this > is a related issue? > I'm trying to do the opposite - building 14 on a 13-STABLE machine. It > fails when trying to build ncurses: > > root@p14s-bsd:/usr/src # uname -v > FreeBSD 13.0-STABLE #0 stable/13-n247584-fdbbd118faa: Sun Oct 10 > 03:25:38 CEST 2021 > root@p14s-bsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC > root@p14s-bsd:/usr/src # git pull > Already up to date. > root@p14s-bsd:/usr/src # git status > On branch main > Your branch is up to date with 'origin/main'. > > nothing to commit, working tree clean > root@p14s-bsd:/usr/src # make buildworld > build.log > (...) > > The full log is at http://eurostar.nebdal.no/build.log > It's all variations over this: > > =3D=3D=3D> lib/ncurses/ncurses (obj,all,install) > Building /usr/obj/usr/src/amd64.amd64/lib/ncurses/ncurses/lib_color.o > /usr/src/contrib/ncurses/ncurses/base/lib_color.c:192:5: error: > implicit declaration of function '_nc_tiparm' is invalid in C99 > [-Werror,-Wimplicit-function-declaration] > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 TIPARM_1(set_a_background, bg), > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ^ > /usr/src/contrib/ncurses/include/nc_tparm.h:81:23: note: expanded from > macro 'TIPARM_1' > #define TIPARM_1(s,a) _nc_tiparm(1,s,a) > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ^ > /usr/src/contrib/ncurses/ncurses/base/lib_color.c:192:5: error: > incompatible integer to pointer conversion passing 'int' to parameter > of type 'const char *' [-Werror,-Wint-conversion] > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 TIPARM_1(set_a_background, bg), > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > /usr/src/contrib/ncurses/include/nc_tparm.h:81:23: note: expanded from > macro 'TIPARM_1' > #define TIPARM_1(s,a) _nc_tiparm(1,s,a) > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ^~~~~~~~~~~~~~~~~ > > -DanielN It is an entirely different storry that deserves its own investigation! I will try to find time in the next couple of days. In the meantile could you provide your make.conf, src.conf and src-env.conf= ? Best regards Bapt From nobody Sun Oct 10 20:41:15 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 2AF7517FE4F0 for ; Sun, 10 Oct 2021 20:41:52 +0000 (UTC) (envelope-from dnebdal@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 4HSDPD08thz4f1q; Sun, 10 Oct 2021 20:41:52 +0000 (UTC) (envelope-from dnebdal@gmail.com) Received: by mail-wr1-x436.google.com with SMTP id e3so15512480wrc.11; Sun, 10 Oct 2021 13:41:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HW6c5h0c08WNYn2ZHhVKhvrPe2X2kuRaLp3MOdDZCtk=; b=YCK+616h8GEosnCL4GPC+d5xZCIT5lS5D7b/Tmt9L9ALxtFpOj1uyGf8CACbtgk6ZG Y2xYBwOWgujICf35elhd+SvaJZCeY04u8d8nwvTabVyn3gikkcv3dnfIf+3t2K4MBui1 uFACTsFU5vYzo6kNNP/yVzDDlGElQRMwFPBSoouaWuuTUnDmYkyZvrzr8viODedMYqVJ 9s4Ph3Ykoc7OBKaLil7GG22mVe4qcxMsKufUJj95SGsIjM+EeSgjvDyQ1fyRF76JPXQq FEINy27AIEWBoSM+YI29Kn1VQLDOA4eKhWTLya8JLbbjI2NZ5yt14tbbDs0eBQQn3Qwt oyZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HW6c5h0c08WNYn2ZHhVKhvrPe2X2kuRaLp3MOdDZCtk=; b=3fZJXTNooza8QHr5DuX8CTsgaRIWAGXRto8cxY2K6r+YBDIKrndWwfBvUAhjmCrwAq jf/upUzVpizFxGFmyogfknPuVGVXS8qzWxYXnWNiiKlYEA4L4aesDVpGNtg39MzzBTb1 Pqb4+sto4fmeQKvDq7fbD+uDu5dn5Y/Q0ijcKfAreH8pTQ0ClEBKecO+qCG7LgS/voXp N+1giahaCd8H9A6cbYz++k/xxE1NewaN75lVbJBHFZxcYoshvcXjR8A2vEralCvS0cQe Lj9pQOYgDvkREX+aFrZBW3JIxhCbvLDsGlETOft5DXWTgiI4CmzNsJJmqLUM+T83R6lC 8sxQ== X-Gm-Message-State: AOAM5308VLas6mpR6QYJww3cHMZ8Cavxi8eghfMEwv1BPfuMFEnmG2Tj JO8R0//OlTqgygDTVUJeSP80xxt38WI4H9JBuOhmc69XB+oh4A== X-Google-Smtp-Source: ABdhPJz3OQh6vkRmaxfFzSj/58fjWQN6YYoTEnRWaINChl2g7NACLLXag0E9nD+vp4Bcc2m3gzc+uCf3DF5AkvYXlYM= X-Received: by 2002:adf:e101:: with SMTP id t1mr20514407wrz.395.1633898510215; Sun, 10 Oct 2021 13:41:50 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 References: <20211010040637.3fw7q6nl7gn7aum4@aniel.nours.eu> <20211010044111.mvzuepff34ztqctq@aniel.nours.eu> <20211010054519.ennyyt3qba3reaop@aniel.nours.eu> <339723c9-24d1-403e-bea8-a6978967db95@FreeBSD.org> In-Reply-To: <339723c9-24d1-403e-bea8-a6978967db95@FreeBSD.org> From: Daniel Nebdal Date: Sun, 10 Oct 2021 22:41:15 +0200 Message-ID: Subject: Re: clang/llvm-tblgen --- ld: error: undefined symbol: setupterm To: Baptiste Daroussin Cc: Warner Losh , Kyle Evans , Konstantin Belousov , Dimitry Andric , FreeBSD User , FreeBSD CURRENT Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4HSDPD08thz4f1q X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Sun, 10 Oct 2021 at 22:17, Baptiste Daroussin wrote: > > > > > I don't know if this is the right place to jump in, but I suspect this > > is a related issue? > > I'm trying to do the opposite - building 14 on a 13-STABLE machine. It > > fails when trying to build ncurses: > > > > root@p14s-bsd:/usr/src # uname -v > > FreeBSD 13.0-STABLE #0 stable/13-n247584-fdbbd118faa: Sun Oct 10 > > 03:25:38 CEST 2021 > > root@p14s-bsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC > > root@p14s-bsd:/usr/src # git pull > > Already up to date. > > root@p14s-bsd:/usr/src # git status > > On branch main > > Your branch is up to date with 'origin/main'. > > > > nothing to commit, working tree clean > > root@p14s-bsd:/usr/src # make buildworld > build.log > > (...) > > > > The full log is at http://eurostar.nebdal.no/build.log > > It's all variations over this: > > > > ===> lib/ncurses/ncurses (obj,all,install) > > Building /usr/obj/usr/src/amd64.amd64/lib/ncurses/ncurses/lib_color.o > > /usr/src/contrib/ncurses/ncurses/base/lib_color.c:192:5: error: > > implicit declaration of function '_nc_tiparm' is invalid in C99 > > [-Werror,-Wimplicit-function-declaration] > > TIPARM_1(set_a_background, bg), > > ^ > > /usr/src/contrib/ncurses/include/nc_tparm.h:81:23: note: expanded from > > macro 'TIPARM_1' > > #define TIPARM_1(s,a) _nc_tiparm(1,s,a) > > ^ > > /usr/src/contrib/ncurses/ncurses/base/lib_color.c:192:5: error: > > incompatible integer to pointer conversion passing 'int' to parameter > > of type 'const char *' [-Werror,-Wint-conversion] > > TIPARM_1(set_a_background, bg), > > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > /usr/src/contrib/ncurses/include/nc_tparm.h:81:23: note: expanded from > > macro 'TIPARM_1' > > #define TIPARM_1(s,a) _nc_tiparm(1,s,a) > > ^~~~~~~~~~~~~~~~~ > > > > -DanielN > > It is an entirely different storry that deserves its own investigation! > > I will try to find time in the next couple of days. > > In the meantile could you provide your make.conf, src.conf and src-env.conf? > > Best regards > Bapt Sure - they're plain enough: # cat /etc/make.conf cat: /etc/make.conf: No such file or directory # cat /etc/src.conf cat: /etc/src.conf: No such file or directory # cat /etc/src-env.conf WITH_META_MODE=YES I did try with meta mode disabled as well, with the same result. -DanielN